no std mode

[artit-io]

I want to run wasmer on bare metal. Is it on the roadmap?

[lachlansneff]

Hi!

Running wasmer on bare-metal is on the long-term roadmap, but it's not a current priority. The main blockers are that wasmer requires the ability to map memory with various protections and that it needs to be able to hook into os-level signals/exceptions.

I have a special place in my heart for rust running without an operating system, so I'd love to see this happen, however.

If you'd like to work on this feature, we'd be happy to accept any contributions and would provide help and advice! Contact us on the spectrum channel if you'd like to pursue this!

[artit-io]

Hi,

I think that's why WebAssembly is sandboxed by default and you can bind your context from outside.

The current (unix) implementation depends on various libc functions that shall be just another optional context to bind. If you want to write a 3D tech demo using typescript for example that is using only a videocore chip and nothing else, you can't use this awesome lib sadly.

[syrusakbary]

Agreed! We would love to have no-std support, as it will be useful for a lot of different scenarios like the one you commented. Right now we are prioritizing other cases like improving speed of the runtime or help the usage of WebAssembly runtime from other languages.

However, we would love to support you on the no-std quest! Is there anything we can do for helping you to achieve that?

[assafmo]

Hi, any progress on no_std? 🙏

[assafmo]

We @enigmampc need no_std in order to run WASM inside an SGX enclave.
Currently, our only solution is to use https://github.com/paritytech/wasmi which is slower, has no built-in gas/metering support and has a slightly worse UX IMO.
So no_std would come in handy.

[Hywan]

What backend would you like to use in no_std mode? It could help us to set priority.

[assafmo]

We are using CosmWasm, and I believe they are using wasmer-singlepass-backend.
But because this doesn't support no_std we are working on replacing wasmer with wasmi inside of CosmWasm.
If wasmer would support no_std we'd use it as it'll save us a lot of work.

[syrusakbary]

@assafmo we would love to support ‘no_std’ in Wasmer.

Right now we are focusing our efforts in making the codebase simpler, but we can guide and help with any contributions.
Would you like to contribute in making Wasmer compatible with ‘no_std’?

[assafmo]

Cc @ethanfrey @webmaster128

@syrusakbary We would love to but let me check if we have the capacity right now. 😊

[stevemk14ebr]

Any updates? This would be really fantastic for embedded platforms and kernels. Wasmer seems one of the most complete wasm engines.

[Hywan]

I would say that maybe 50% of our crates can be used in no_std. I don't know how much work would be required to me it up to 100%. Anyone would like to help on that front? I can coordinate the project.

[1c3t3a]

I would like to help - if I can. I'm currently preparing for my bachelor thesis about virtualization with WASM in the embedded area, where I would kinda depend on a no_std wasmer version.

[syrusakbary]

Awesome.

I think there was some work done on a PR that you can probably leverage on:
#2168

Feel free to create a side PR with the progress so nostd support can be merged upstream :)

[1c3t3a]

Great thanks for the quick response! I am going to head over to the PR and have al look!

[ethindp]

Any update on this? For mmap/mprotect you could just have a trait for the host to define its own functions for that functionality. Then you wouldn't need to care how the host creates executable pages in memory. Same for signals -- just use a trait for handler functions that either raises the signal or whatever.

What else is blocking this? Other than mmap/mprotect and signals?

[nerdyguy87]

What backend would you like to use in no_std mode? It could help us to set priority.

Hello. For our project we are looking to use Wasmr on bare-metal for aarch64 and RiscV64. We would need to be able to use the cranelift backend in no_std mode. Our team is disheartened that no_std is set as a low priority and have reluctantly been looking into alternatives like wasmi. Could we please request higher priority support with this?

[ethindp]

I'm looking to use the cranelift backend as well. Its incredibly disheartening to see that all the actually good Wasm implementations put no_std support as a very low priority feature. Wasmi is the only no_std implementation available, and its fallen extremely far behind and is slow (and I also find the API convoluted). (It doesn't help that my research shows that nobody seems to publicly use it either, which means that, for all intents and purposes, people who use it are left to their own devices.)

[1c3t3a]

I agree, but to be fair, reaching no_std support is a fairly big step and a lot of work. Also maintaining it can be hard, as every dependency potentially breaks no_std. @nerdyguy87 did you take a look at Wasm-Micro-runtime? It has JiT, AoT and Interpreter support and runs on several systems (Zephyr, vxworks, ESP-IDF, SGX).

Generally I think support for Espressif's Rust standard library implementation is easier to reach, as it mostly requires changes to libc and the memory mapping code. Then it's at least possible to run Wasmer on the Espressif chips.

[stevemk14ebr]

Strong disagree with the espressif idea. General no_std support is much better, in my use case I need no_std to run wasm in the windows kernel. This execution environment perfectly matches the use case of no_std, just need some allocator apis. I do not care about targeting specific chip and that would only solve a tiny sliver of all use cases while still being a maintenance burden

[1c3t3a]

As far as I can tell the general idea is to compile nearly any rust std dependendant code. That wouldn't introduce a maintenance burden at wasmers.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stevemk14ebr]

bad bot

[artit-io]

Some point next year I will have a few months to look into this properly, but I doubt it can be done as a single PR. I currently use a bare minimal linux to run wasmer and that kind of defeats the point.

[Lucky4Luuk]

Any more updates on this? I'd to love to use wasmer in a no_std environment, with alloc support, regardless of the backend. The performance gains over wasmi would be very useful

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[assafmo]

Hey guys, any update on this?

[stevemk14ebr]

Disable this bot please. It undermines any will to submit issues if they just get closed without comment

[stevemk14ebr]

Has the status of this changed at all with the release of 5.0? https://wasmer.io/posts/introducing-wasmer-v5 states:

"Wasmi: one of the most optimal Rust WebAssembly interpreters. Ideal if you want to use Wasm in nostd environments or blockchains with a pure Rust codebase (wasmi feature)"

Wasmi is the runtime I switched to instead of wasmer because it supports no_std completely. Now that wasmer has the wasmi backend, has this issue progressed? I do not yet see a no_std feature flag in the wasmer cargo.toml, is this instead the 'wasmi' feature?

I still face performance issues with wasmi (it's an interpreter) but using wasmer for a nicer interface would still be an improvement. Really hope to see wasmer grow to support this. Wasm is IDEAL for executing untrusted code in embedded environments safely (or just sandboxing in general)!