5 ms·

Looks interesting. Based on prior experience, here are some concerns people will bring up with this approach: 1. Spectre. You may have to assume the plugin cod

Looks interesting. Based on prior experience, here are some concerns people will bring up with this approach: 1. Spectre. You may have to assume the plugin code can read anything in the address space including any secrets like passwords, keys, file contents etc. If the plugin can't communicate with the outside world this may not be a problem. 2. When you say WASM has a "sandboxing architecture", this is only partially true. It's quite easy to define a simple language that doesn't provide any useful IO APIs and then claim it's sandboxed - that's practically the default state of a new language that's being interpreted. The problems start when you begin offering actual features exposed to the sandboxed code. The app will have to offer APIs to the code being run by the WASM engine and those APIs can/will contain holes through which sandboxed code can escape. If you look at the history of sandboxing, most sandbox escapes were due to bugs in the higher privileged code exposed to sandboxed code so it could be useful, but you can't help devs with that. 3. WASM is mostly meant for low level languages (C, C++, Rust etc). Not many devs want to write plugins in such low level languages these days, they will often want to be using high level languages. Even game engines are like that: "plugin" code is often written in C#, Lua, Blueprint, etc. This is especially true because WASM doesn't try to solve the API typing/object interop problem (as far as I know?), which is why your example APIs are all C ABI style APIs - the world moved on from those a long time ago. You'll probably end up needing something like COM as otherwise the APIs the host app can expose will be so limited and require so much boilerplate that the plugin extension points will just be kind of trivial.

fiedzia 4y ago
>WASM doesn't try to solve the API typing/object interop problem There many initiative around wasm, one of them being WebAssembly interface types, aimed at that problem. This makes using wasm simple.
bhelx 4y ago
Lots of good points here. I'll try my best to address them. But you are right, There aren't really complete answers to each of these problems. Regarding #1, it's good to point out that spectre is still an ongoing problem. wasmtime, the runtime we use, has mitigations for spectre but things will likely come up. I think we need more time and tools to work on things like detecting attacks and mitigating future problems. Fortunately there are some big companies working on it. Our team cannot solve that problem. Regarding #2, sandboxing here refers to the memory access model and fault isolation. For each capability you give the plugin you may introduce risk. We don't claim to address this problem but I think education and mitigation are good goals for us. Regarding #3, I think there has been some good progress here. I have an experimental C# plugin PDK and a JS one based on quickjs. We also support Haskell. I think there will be improvement here. And regarding the ABI comment, there are going to be layers on top of this to make it more ergonomic.
titzer 4y ago
> 3. WASM is mostly meant for low level languages I've been saying it for years, but I think finally 2023 has the chance of being the year in which Wasm GC ships and managed languages start targeting Wasm more widely. We've made a lot of progress with the design, and V8 has a basically complete implementation. Google is targeting some internal apps to Wasm GC and seeing perf improvements over compile-to-JS, so I think this will likely be a success.
- zozbot234 4y ago
  There's no such thing as one-size-fits-all GC. Wasm GC will probably be just as successful as other attempts at generic "managed" runtimes, which is to say, not very.
  - titzer 4y ago
    > There's no such thing as one-size-fits-all GC. Two aspects to that. One is the implementation, e.g. the GC algorithm. They vary widely in their performance characteristics. For the most part, they are semantically invisible. I fully expect many different engines to have different algorithms, and ultimately you can choose and tune the GC algorithm to your application's needs. Two is the semantics. We're aware of many failed attempts to make generic runtimes, and a critical factor is how universal the object model is. Of the many over the years, most have originated for a single language or paradigm of languages and have, in some sense, too high a level of abstraction. Wasm GC is a lower level of abstraction (think: typed structs), from which higher level constructs are implemented (like vtables, objects, classes, etc). Being lower level is a tradeoff towards universality that we have consciously made. That said, there are downsides, such as more casts, because it gets increasingly harder to safely encode invariants of source languages to avoid such casts at the lower level. We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
    - zozbot234 4y ago
      > We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these. You could encode arbitrary invariants by implementing verifiable proof-carrying code within Wasm. Then a wasm-to-native compiler could be designed to take advantage of such invariants in order to dispense with these overheads.
thingification 4y ago
Thread on spectre and capability security (which I gather from a glance here that wasmtime is using on some level https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...): https://groups.google.com/g/cap-talk/c/NSDM-05fEuU/ https://groups.google.com/g/cap-talk/c/NSDM-05fEuU/
singularity2001 4y ago
3. WASM is mostly meant for low level languages At least the common plugin language lua runs in wasm, and micropython is less than a megabyte in wasm, so that point is a bit weak. (having an extra level of abstraction may make the plugins minimally slower, but running lua in wasm adds an extra level of security)
outside1234 4y ago
For #1, I believe they are proposing that the plug-ins run in their own memory space with the only shared anything are the parameters coming in.

fiedzia 4y ago

>WASM doesn't try to solve the API typing/object interop problem There many initiative around wasm, one of them being WebAssembly interface types, aimed at that problem. This makes using wasm simple.

bhelx 4y ago

Lots of good points here. I'll try my best to address them. But you are right, There aren't really complete answers to each of these problems. Regarding #1, it's good to point out that spectre is still an ongoing problem. wasmtime, the runtime we use, has mitigations for spectre but things will likely come up. I think we need more time and tools to work on things like detecting attacks and mitigating future problems. Fortunately there are some big companies working on it. Our team cannot solve that problem. Regarding #2, sandboxing here refers to the memory access model and fault isolation. For each capability you give the plugin you may introduce risk. We don't claim to address this problem but I think education and mitigation are good goals for us. Regarding #3, I think there has been some good progress here. I have an experimental C# plugin PDK and a JS one based on quickjs. We also support Haskell. I think there will be improvement here. And regarding the ABI comment, there are going to be layers on top of this to make it more ergonomic.

titzer 4y ago

> 3. WASM is mostly meant for low level languages I've been saying it for years, but I think finally 2023 has the chance of being the year in which Wasm GC ships and managed languages start targeting Wasm more widely. We've made a lot of progress with the design, and V8 has a basically complete implementation. Google is targeting some internal apps to Wasm GC and seeing perf improvements over compile-to-JS, so I think this will likely be a success.

zozbot234 4y ago
There's no such thing as one-size-fits-all GC. Wasm GC will probably be just as successful as other attempts at generic "managed" runtimes, which is to say, not very.
- titzer 4y ago
  > There's no such thing as one-size-fits-all GC. Two aspects to that. One is the implementation, e.g. the GC algorithm. They vary widely in their performance characteristics. For the most part, they are semantically invisible. I fully expect many different engines to have different algorithms, and ultimately you can choose and tune the GC algorithm to your application's needs. Two is the semantics. We're aware of many failed attempts to make generic runtimes, and a critical factor is how universal the object model is. Of the many over the years, most have originated for a single language or paradigm of languages and have, in some sense, too high a level of abstraction. Wasm GC is a lower level of abstraction (think: typed structs), from which higher level constructs are implemented (like vtables, objects, classes, etc). Being lower level is a tradeoff towards universality that we have consciously made. That said, there are downsides, such as more casts, because it gets increasingly harder to safely encode invariants of source languages to avoid such casts at the lower level. We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
  - zozbot234 4y ago
    > We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these. You could encode arbitrary invariants by implementing verifiable proof-carrying code within Wasm. Then a wasm-to-native compiler could be designed to take advantage of such invariants in order to dispense with these overheads.

thingification 4y ago

Thread on spectre and capability security (which I gather from a glance here that wasmtime is using on some level https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...): https://groups.google.com/g/cap-talk/c/NSDM-05fEuU/ https://groups.google.com/g/cap-talk/c/NSDM-05fEuU/

singularity2001 4y ago

3. WASM is mostly meant for low level languages At least the common plugin language lua runs in wasm, and micropython is less than a megabyte in wasm, so that point is a bit weak. (having an extra level of abstraction may make the plugins minimally slower, but running lua in wasm adds an extra level of security)

outside1234 4y ago

For #1, I believe they are proposing that the plug-ins run in their own memory space with the only shared anything are the parameters coming in.