Support for embedded bare-metal/no_OS/no_std/realtime OS hosting?

[eddyp]

Coming from a real-time embedded/bare-metal/no-std background, I am really thinking wasi-core could benefit even finer break-up than POSIX APIs (yes, I understand core is already finer, but read on).

For systems without "fat"/general puropose OSes, for instance, threads could be unavailable, while other WASI APIs such as crypto-related APIs could exist. Another example, file systems could also be lacking, or could be very limited (e.g. a very thin layer flash-based FS), but these could be unnecessary for specific applications where sand-boxing and only particular APIs are interesting and necessary (e.g. ethernet).

Such tailored systems exist very often in the embedded space, but allowing exensibility while keeping the sand-boxing to such a system is a very attractive goal in a domain where work is continuously increasing, while requirements also get tougher.

Is there anyone else but myself interested in this topic?

In particular, I am thinking a minimal WASI environment could be implemented even on such systems, and one could develop and debug the WASM apps on some fatter system like wasmtime by restricting the available APIs to the ones available on the embedded WASI machine.

As an example, at the lowest end, a no-OS application with mbedTLS could implement a WASI environment which would allow a wasm module implemented in Rust to implement the second 2-Factor-Auth method for some system using mbedTLS primitives exposed through a wasi-crypto API.

[dumblob]

Regarding fs-related stuff see e.g. #1 (comment) , #1 (comment) , #13 (comment) , #62 etc.

[programmerjake]

I'm planning on using wasm to write deterministic plugins for a future Rust version of my game, this would be done by limiting the API by removing networking, cryptographic randomness, time, and threading APIs and having a read-only filesystem.

[tschneidereit]

@eddyp, yes, these kinds of use cases are very much in scope for WASI, and the plan is for WASI to indeed be broken up into finer-grained modules—much along the lines of what you describe. See this PR by @sunfishcode.

Also note that Wasmtime itself will be usable for these use cases, by making it possible to remove any and all WASI modules, and other functionality not needed.

@programmerjake, this should address your use case just as well as @eddyp's, as far as I can tell.

[vshymanskyy]

BTW, while experimenting with WASI and wasm3 interpreter, we got a simple WASI module working on ESP32:

source: wasm3/wasm3#26 (comment)

[eddyp]

BTW, while experimenting with WASI and wasm3 interpreter, we got a simple WASI module working on ESP32:

source: wasm3/wasm3#26 (comment)

How essential is the 64kiB requirement? Would it work in a more constrained environment (e.g. 8kiB or even 16kiB)?

[vshymanskyy]

@eddyp Please elaborate, which exactly 64kiB are you talking about? If you're talking about stack size requirement for this specific WASI example - it can be improved.
But if you're referring to 64KiB from Minimum System Requirements, I think a reasonable WASM engine can hardly be smaller.

[pchickey]

WebAssembly linear memory pages are 64KiB in size, and there is no way to support smaller allocations (or page sizes). The page size was selected to ensure that all modern platforms can support it - even though most systems use a 4k page, there are some older ARMv7 chips out there that have 64K pages.

[sunfishcode]

Some ARM64 devices use 64KiB pages as well; it's determined by the OS, so wasm runtimes don't always have the option of changing the page size.

[eddyp]

@eddyp Please elaborate, which exactly 64kiB are you talking about? [..]
But if you're referring to 64KiB from Minimum System Requirements, I think a reasonable WASM engine can hardly be smaller.

I was referring to the Minimum System Requirements.

@pchickey In contrained systems, e.g Cortex-M7/M4 with the total SRAM size of 128KiB, giving 64KiB just to WASI/WASM is very prohibitive. I was thinking that for such systems lowering the system memory requirements is a must to be able to run (maybe untrusted) WASM code in an isolated environment.

@sunfishcode Do you mean that a particular wasm runtime could optionally change the page size to fit their scenarios/needs without risking WASI examples breaking?

[pchickey]

A wasm runtime must use a 64k page size to be spec compliant: https://webassembly.github.io/spec/core/exec/runtime.html#syntax-meminst - its required for the data segment and the memory instructions to work correctly. Changing that aspect of the spec is a concern you'd have to take to the Wasm CG - it is outside of the scope of the WASI sub-group.

[eddyp]

A wasm runtime must use a 64k page size to be spec compliant: https://webassembly.github.io/spec/core/exec/runtime.html#syntax-meminst - its required for the data segment and the memory instructions to work correctly.

Thanks for the clarification. I'll have to fix this some other way.
At worst, I'll hack a non-compliant WASI which either lies about giving 64K and gives only a smaller usable amount (e.g. 16KiB), either by repeating the first true block, or by dropping everything past the limit and always return 0 as contents.