6 ms·

As somebody who's in the process of building a sandbox for RISC-V 64 Linux ELF executables, even I'm still on the fence. The problem is that in WASM-land we're

As somebody who's in the process of building a sandbox for RISC-V 64 Linux ELF executables, even I'm still on the fence. The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime. Meaning... no, I can't really just output WASM from Go or Rust and it'll work, there's more to it, much more to it. With a RISC-V userland emulator I could compile that to WASM to run normal binaries in the browser, and provide a sandboxed syscall interface (or even just pass-through the syscalls to the host, like qemu-user does when running natively). Meaning I have high compatibility with most of the Linux userland within a few weeks of development effort. But yes, threads, forking, sockets, lots of edge cases - it's difficult to provide a minimal spoof of a Linux userland that's convincing enough that you can do interesting enough things, but surprisingly it's not too difficult - and with that you get Go, Rust, Zig, C++, C, D etc. and all the native tooling that you'd expect (e.g. it's quite easy to write a gdbserver compatible interface, but ... you usually don't need it, as you can just run & debug locally then cross-compile).

hardwaresofton 2y ago
> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime. At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction. For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP: https://github.com/WebAssembly/wasi-http https://github.com/WebAssembly/wasi-http It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against. As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc: https://github.com/webassembly/wasi-libc https://github.com/webassembly/wasi-libc Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months). The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.
- quesomaster9000 2y ago
  I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. There are a few niches where standardization of interfaces and discoverability will be extremely valuable in terms of interoperability and reducing the development effort to bring-up products that deeply integrate with many things, where currently each team has to re-invent the wheel again for every end-user product they integrate with, with the more ideal alternative being that each product provides their own implementations of the standard interfaces that are plugged into interfaces. But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal.
  - hardwaresofton 2y ago
    > I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. I think we can at least say WebAssembly + WASI is distinct from DLL hell because at the very least your DLLs will run everywhere, and be intrinsically tied to a version and strict interface. These are things we've just never had before, which is what makes it "different this time". Having cross-language runnable/introspectable binaries/object files with implicit descriptions of their interfaces that are this approachable is new. You can't ensure semantics are the same but it's a better place than we've been before. > But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal. A bit hard to understand here the difference you were intending between discrete commands and a self-describing interface, could you explain? I'd also argue that WASM + Component Model/WASI as a (virtual) instruction set versus RISC-V are very different!
    - pjmlp 2y ago
      DLLs already run everywhere since CLR became cross platform. Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through. https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL
fwsgonzo 2y ago
As someone who has written a RISC-V sandbox for that purpose, I say stay the course. We need more competition to WASM. At the end you'll find that register machines make for faster interpreters than Harvard architectures. You can have a look at libriscv or message me if you need any help. Source: https://libriscv.no/docs/performance/ https://libriscv.no/docs/performance/
Joker_vD 2y ago
WASM approach to injecting the host-interaction API seems to me to be similar to what EFI does. You are provided with a table full of magical functions on startup, and that's how you can interact with the host. Some functions weren't provided there? Tough luck.

hardwaresofton 2y ago

> The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime. At the application level, you're generally going to write to the standards + your embedding. Companies that write embeddings are encouraced/incentivized to write good abstractions that work with standards to reduce user friction. For example, for making HTTP requests and responding to HTTP requests, there is WASI HTTP: https://github.com/WebAssembly/wasi-http https://github.com/WebAssembly/wasi-http It's written in a way that is robust enough to handle most use cases without much loss of efficiency. There are a few inefficiencies in the WIT contracts (that will go away soon, as async lands in p3), but it represents a near-ideal representation of a HTTP request and is easy for many vendors to build on/against. As far as rewriting the world, this happens to luckily not be quite true, thanks to projects like wasi-libc: https://github.com/webassembly/wasi-libc https://github.com/webassembly/wasi-libc Networking is actually much more solved in WASI now than it was roughly a year ago -- threads is taking a little longer to cook (for good reasons), but async (without function coloring) is coming this year (likely in the next 3-4 months). The sandboxing abilities of WASM are near unmatched, along with it's startup time and execution speed compared to native.

quesomaster9000 2y ago
I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. There are a few niches where standardization of interfaces and discoverability will be extremely valuable in terms of interoperability and reducing the development effort to bring-up products that deeply integrate with many things, where currently each team has to re-invent the wheel again for every end-user product they integrate with, with the more ideal alternative being that each product provides their own implementations of the standard interfaces that are plugged into interfaces. But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal.
- hardwaresofton 2y ago
  > I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. I think we can at least say WebAssembly + WASI is distinct from DLL hell because at the very least your DLLs will run everywhere, and be intrinsically tied to a version and strict interface. These are things we've just never had before, which is what makes it "different this time". Having cross-language runnable/introspectable binaries/object files with implicit descriptions of their interfaces that are this approachable is new. You can't ensure semantics are the same but it's a better place than we've been before. > But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal. A bit hard to understand here the difference you were intending between discrete commands and a self-describing interface, could you explain? I'd also argue that WASM + Component Model/WASI as a (virtual) instruction set versus RISC-V are very different!
  - pjmlp 2y ago
    DLLs already run everywhere since CLR became cross platform. Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through. https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL

fwsgonzo 2y ago

As someone who has written a RISC-V sandbox for that purpose, I say stay the course. We need more competition to WASM. At the end you'll find that register machines make for faster interpreters than Harvard architectures. You can have a look at libriscv or message me if you need any help. Source: https://libriscv.no/docs/performance/ https://libriscv.no/docs/performance/

Joker_vD 2y ago

WASM approach to injecting the host-interaction API seems to me to be similar to what EFI does. You are provided with a table full of magical functions on startup, and that's how you can interact with the host. Some functions weren't provided there? Tough luck.