RFC notifications bot (Oct 18 2024 at 15:31): RFC notifications bot (Oct 18 2024 at 15:31):rvolosatovs opened PR #39 from rvolosatovs:wasmtime-plugins to bytecodealliance:main:
Refs https://github.com/bytecodealliance/wasmtime/issues/7348
RFC notifications bot (Oct 18 2024 at 16:42):programmerjake commented on PR #39:
i don't see a way to access a .so global variable from wasm...
RFC notifications bot (Oct 18 2024 at 17:46):rvolosatovs commented on PR #39:
i don't see a way to access a .so global variable from wasm...
indeed, I did not add this functionality in the current
wasi-dldraft, it's really just an approximation sufficient for a very basic PoCDoes https://github.com/rvolosatovs/wasi-dl/pull/1 address your concern?
alloccan be interpreted as anyffi-typeor even a function.Perhaps
resource symbolis redundant altogether and lookups should just returnallocresources, which can be interpreted as functions
RFC notifications bot (Oct 18 2024 at 17:50):rvolosatovs edited a comment on PR #39:
i don't see a way to access a .so global variable from wasm...
indeed, I did not add this functionality in the current
wasi-dldraft, it's really just an approximation sufficient for a very basic PoCDoes https://github.com/rvolosatovs/wasi-dl/pull/1 address your concern?
alloccan be interpreted as anyffi-typeor even a function.Perhaps
resource symbolis redundant altogether and lookups should just returnallocresources, which can be interpreted as functionsEdit: added https://github.com/rvolosatovs/wasi-dl/pull/1/commits/30ea77f0d5679f8382603890408c6fef0bc4713b
RFC notifications bot (Oct 18 2024 at 17:52):rvolosatovs updated PR #39.
RFC notifications bot (Oct 18 2024 at 17:53):rvolosatovs edited a comment on PR #39:
i don't see a way to access a .so global variable from wasm...
indeed, I did not add this functionality in the current
wasi-dldraft, it's really just an approximation sufficient for a very basic PoCDoes https://github.com/rvolosatovs/wasi-dl/pull/1 address your concern?
alloccan be interpreted as anyffi-typeor even a function.Perhaps
resource symbolis redundant altogether and lookups should just returnallocresources, which can be interpreted as functionsEdit: added https://github.com/rvolosatovs/wasi-dl/pull/1/commits/30ea77f0d5679f8382603890408c6fef0bc4713b
Edit 2: updated PR with https://github.com/bytecodealliance/rfcs/pull/39/commits/b48bdaa743642403ab3ac771495bd882f571d88b
RFC notifications bot (Oct 18 2024 at 18:08):programmerjake commented on PR #39:
Does rvolosatovs/wasi-dl#1 address your concern?
yes!
RFC notifications bot (Oct 18 2024 at 19:32):rvolosatovs updated PR #39.
RFC notifications bot (Oct 18 2024 at 19:34):rvolosatovs edited PR #39:
Refs https://github.com/bytecodealliance/wasmtime/issues/7348
RFC notifications bot (Oct 18 2024 at 19:37):rvolosatovs commented on PR #39:
Did a small update to ensure the symbol lookups are typed https://github.com/bytecodealliance/rfcs/pull/39/commits/b9ae4c912db5d96956c1b57a2e74696a55db6b62
RFC notifications bot (Oct 21 2024 at 16:15):sunfishcode commented on PR #39:
Such interface is unsafe and it must be used with extreme care, however that is no different from any other host plugin, which would be loaded via
dlopen.There are two kinds of unsafe relevant here. One is whether the plugin code is unsafe, and I agree that this is basically the same with any host plugin system we'd design here. The other is whether Wasm code using the plugin code is unsafe.
The libffi-style approach in this proposal looks like it means that we'd additionally have to treat the Wasm that calls the code as unsafe by default, and while there are potential ways to make it safe, they aren't described here.
Also, the libffi-style approach in this proposal looks like it would mean that the Wasm would not be portable, in general, because libffi doesn't encapsulate all C ABI details. What is
off_ta typedef for? What is the value ofENOENT? And so on.[wasi-dl]-based approach also provides greater security, since the implementation of [wasi-dl] may restrict the set of libraries allowed to be loaded and potentially define the exact signatures for symbols defined in them.
This proposal does not currently describe how this would work. And, signatures alone would not be sufficient, because libffi-style bindings also include raw pointers.
Perhaps it would be possible to design an interface description language sophisticated enough to describe these interfaces, including signatures, lifetime information, synchronization information, and perhaps also resource lifetimes (eg. open files that need to be explicitly closed and not used thereafter), and perhaps eventually even a way to describe C
unions, or some safe variant-like subset of them. If this rfc implies the design of a new interface description language, it'd be good to say more about what that looks like.As an alternative to exposing wasi-dl interface to (plugin) components, we could use the dynamic libraries themselves as the host plugins. For that we would need to carefully design a set of conventions specific to wasmtime for such plugins to be able to define their exports and expose them to components.
Such an approach would require custom-built dynamic libraries for plugins, if an existing library was desired to be used, an "adapter" library would need to be built, which would in turn dynamically-load that library.
It looks like this proposal would also usually want "adapter" libraries too, or at least adapter layers, because I don't expect we'll want normal Wasm code talking directly to these low-level libffi-style APIs, for ergonomics, language-independence, portability, and potential security reasons. And these adapters are going to be tedious to write and maintain, because they need to be written for each source language that needs them, and they'll have a lot of repetitive low-level code. I imagine we'd pretty quickly find ourselves wanting bindings generators for this task.
And if we're going to design a language-independent sandboxable interface description language with tooling around it for generating bindings, we should think carefully about whether or not we already have one, and what relationships we want :smile:.
Last updated: Oct 23 2024 at 20:03 UTC