wasmerio / wasmer

🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten
https://wasmer.io
MIT License
18.47k stars 789 forks source link

no std mode #217

Open artit-io opened 5 years ago

artit-io commented 5 years ago

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

lachlansneff commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Hi, any progress on no_std? :pray:

assafmo commented 4 years ago

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 commented 4 years ago

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

assafmo commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

Cc @ethanfrey @webmaster128

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

stevemk14ebr commented 3 years ago

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

Hywan commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Awesome.

I think there was some work done on a PR that you can probably leverage on: https://github.com/wasmerio/wasmer/pull/2168

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

1c3t3a commented 3 years ago

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

ethindp commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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[bot] commented 1 year ago

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 commented 1 year ago

bad bot

artit-io commented 1 year ago

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 commented 1 year ago

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[bot] commented 6 months ago

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 commented 6 months ago

Hey guys, any update on this?

stevemk14ebr commented 6 months ago

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