noah VS workers-wasi

The other day I came across an interesting "alternative" to WASM which gives you OS portability using fully native code, without CPU portability, the latter seeming not that big of a deal these days anyway as cross compilers have got quite good and there are only two CPU archs in wide usage anyway.

The idea is to simply run normal Linux binaries on macOS and Windows. How? You create a virtual machine using the Mac/Windows APIs without any OS inside, in fact without even any virtual hardware. It's literally just a new address space and some trivial min-viable VM configuration. Then you map the ELF binary and a ld.so into the VM with a minimal ELF interpreter, kick off execution and anytime there's a syscall you trap it and translate to the host OS syscalls. It can work quite well on macOS because the syscall interface is so similar.

Note that this sort of VM is not:

• A sandbox

• A hardware abstraction

Apps run this way hold all their data in the filing system of the host OS, they use the network stack of the host OS, etc. The VM is only being used to allow trapping and emulation of the syscall interface. The app isn't aware that it's being run in a special CPU mode on top of an emulated kernel.

Advantages: lightweight, simple, apps can use all CPU features, can run at native speed, the Linux syscall interface is highly stable, based on POSIX specifications and you can easily pick a subset of it to standardize.

Disadvantages: requires the emulator, apps exposed to missing features or quirks of the host OS e.g. Windows file system performance is much lower than Linux.

WSL1 sort of worked that way, albeit without the VM aspect that lets userspace apps do it. They abandoned it partly for performance reasons and users expected all existing Linux apps to just work. But WASM doesn't target existing apps. It expects developers to bend and do things the WASM way, and accepts that not all apps are compatible with it, so that's not necessarily a problem.

An example of how to implement this is NOAH:

https://github.com/linux-noah/noah/

There was an attempt, but it was archived https://github.com/linux-noah/noah

The examples seemed clear enough to read (I did not test them), but I felt than even when teaching by example there needs to be more overview and explanation. I.e., I would prefer an overview of WASM structure and use with examples, rather than just the examples. (I have some (but limited) experience using WASM.)

As for the utility of wasm, note also that Cloudflare workers can run WASM on edge servers [1], and that the Swift community has some support for compiling to wasm [2].

I've never really understood how wasm could do better than java bytecode, but I've been impressed with how much people are using lua and BPF. More generally, in a world of federated programming, we need languages client can submit that providers can run safely, without obviously leaking any secret sauce -- perhaps e.g., for model refinement or augmented lookup.

[1] https://github.com/cloudflare/workers-wasi

Those are great questions! I believe Emscripten will be required for some cases as it provides more features for targeting a Web Browser. If WASI is the only requirement for a Wasm module, then there are three possible solutions:

- Use a library that provides the WASI bindings in a browser environments: there are some OSS projects that provides WASI bindings on top of browser technologies. For example, workers-wasi from Cloudflare [1]. It could be even another Wasm module that provides the implementation for the main one. I know the people from Loophole Labs are experimenting with virtual filesystems (VFS) [2].

- Browsers provides a WASI implementation: server-oriented runtimes like NodeJS are already providing these bindings (under a experimental flag). I shouldn't have stated that as a fact, as browsers may provide it or not. However, I saw in the past the Google Chrome team experimenting with WASI and the browser FileSystem API [3]. So, I think it may happen :)

- [1] https://github.com/cloudflare/workers-wasi

- [2] https://www.youtube.com/watch?v=46jZSXVxYPw

- [3] https://github.com/GoogleChromeLabs/wasi-fs-access

Indeed, some people are doing this:

- WASI once had an official polyfill https://wasi.dev/polyfill/, now apparently succeeded by https://github.com/bjorn3/browser_wasi_shim

- wasmer-js provides a JS polyfill for WASI https://docs.wasmer.io/integrations/js/wasi

- Cloudflare has a WIP polyfill https://github.com/cloudflare/workers-wasi

I'm generally leery of non-temporary polyfills, so I'm not sure that any of these feel like a long-term viable option for me.

I think modern C++ could be perfectly viable as well. Maybe https://github.com/cloudflare/workers-wasi would be a good starting point? I'm not too knowledgeable on the subject. Exciting times though, I think WASM might be the great equalizer.

While there is a WASI implementation for Workers: cloudflare/workers-wasi, I prefer to implement each import manually - especially when there are so few and especially while I am still experimenting. This helps me to keep the full picture of what's going on.