Show HN: Munal OS: a graphical experimental OS with WASM sandboxing
Showing off the first version of Munal OS, an experimental operating system I have been writing in Rust on and off for the past few years.
https://github.com/Askannz/munal-os
It's an unikernel design that is compiled as a single EFI binary and does not use virtual address spaces for process isolation. Instead, applications are compiled to WASM and run inside of an embedded WASM engine.
Other features:
* Fully graphical interface in HD resolution with mouse and keyboard support
* Desktop shell with window manager and contextual radial menus
* PCI and VirtIO drivers
* Ethernet and TCP stack
* Customizable UI toolkit providing various widgets, responsive layouts and flexible text rendering
* Embedded selection of applications including:
* A web browser supporting DNS, HTTPS and very basic HTML
* A text editor
* A Python terminal
Demo video: https://streamable.com/5xqjcf
This is really interesting and I was wondering how you implemented that using Wasmi. Seems like the code for that is here:
https://github.com/Askannz/munal-os/blob/2d3d361f67888cb2fe8...
It might interest you that newer versions of Wasmi (v0.45+) extended the resumable function call feature to make it possible to yield upon running out of fuel: https://docs.rs/wasmi/latest/wasmi/struct.TypedFunc.html#met...
Seeing that you are already using Wasmi's fuel metering this might be a more efficient or failure proof approach to execute Wasm apps in steps.
An example for how to do this can be found in Wasmi's own Wast runner: https://github.com/wasmi-labs/wasmi/blob/019806547aae542d148...
> It might interest you that newer versions of Wasmi (v0.45+) extended the resumable function call feature to make it possible to yield upon running out of fuel:
That is really interesting! I remember looking for something like that in the Wasmi docs at some point but it must have been before that feature was implemented. I would probably have chosen a different design for the WASM apps if I had it.
Wasmi's fuel metering can be thought of as is there was an adjustable counter and for each instruction that Wasmi executes this counter is decreased by some amount. If it reached 0 the resumable call will yield back to the host (in this case the OS) where it can be decided how to, or if, the call shall be resumed.
For efficiency reasons fuel metering in Wasmi is not implemented as described above but I wanted to provide a simple description.
With this, one is no longer reliant on clocks or on other measures to provide each call its own time frame by providing an amount of fuel for each Wasm app that can be renewed (or not) when it runs out of fuel. So this is useful for building a Wasm scheduler.
Thanks! I have lots more too. Are there directions in space? What kind of matter is fire made of? If you shine a laser into a box with one-way mirrors on the inside, will it reflect forever? Do ants feel like they're going in regular motion and we're just going in slow motion? Why do people mainly marry and make friends with people who look extraordinarily similar to themselves? How do futures work in Rust? Why is the C standard still behind a paywall? Let me know if you need any more great questions.
Seems to me that a bigger downside is that the more apps you have open, the slower each one will become. I don't remember ever having more than like 10 open, but I've definitely had 30 tabs open, so if they're each separate procs then wouldn't that slow each one down by 30x? I guess if the whole computer is fast enough that's fine, but intense processes like video renderers would slow down noticably, even if not fast, even if just going from 1sec to 30sec. But in any case this is a really, really clever shortcut for the general case to get a whole operating system working, which is no small feat, and really exciting!
I have huge respect for unikernel designs, and this looks amazingly festureful. & Yet… I don't know why it matters to me as much as it does, but I want so very much for wasm to be useful for more than one big precompiled app.
There's all sorts of work going into wasi preview3 right now, to allow sync and async code to co-exist. Once that happens, it feels like wasm will finally have all the necessary ingredients down to be an everything runtime (although I'd hoped the host-object bridging was going to get more love too, & it's not clear to me that there's any itnent to go beyond js-based bridges like rust web-sys, on and on).
I hope we see more interest in wasm runtimes being used to host more dynamic sub environments, to host not just one amazing process but many processes. The promise of wasm components is to give us: standard, portable, lightweight, finely sandboxed, cross-language, compositional module (according to the wonderful talk linked below), and it seems so near, but this status quo of it being used so extensively in unikernel like applications, needing everything compiled ahead of time, feels like the area I want to see wasm expanding into not as a specification (the spec seems there!) but as a practicable doable thing, like what I want wasm components to be good for. Not just a distribution format but a runtime capability.
What is a Component (and Why) https://youtu.be/y3x4-nQeXxc
You can see a snippet of it running (and rendering Hacker News) in the demo video.
This readme is really, really interesting to read through.
Why did you use wasmi instead of wasmtime?
I might actually try to use this OS inside a VM.
Half of me wants to port my own reactive GUI lib to Munal.
I just watched the demo video of Munal OS and am still in awe of all of its features. Really impressive work!
If you are talking about the app isolation through virtualization, then I've been living in this future for quite some time with Qubes OS. The isolation there is also extremely reliable.
SPECTRE and MELTDOWN enter the chat
Every few years since Xerox PARC, we get yet another attempt to bytecode userspace.
So far only IBM i, ChromeOS and Android managed to stick around, mostly thanks for their owners having the "my way or the highway" attitude, with management willing to support the teams no matter for how long it takes.
/rant mode off
Anyway, all the best for the project, looks cool.
Now that Redox aims to support WASI too, it would be interesting to see if the syscall interfaces of these two can grow together other time, even as the implementation strategy remains radically different.
That is a tad dramatic. You could also say the same thing about any art form.
- Painters spend all of their time working on artwork only a few people will ever see!
- Musicians don't realize how their time is wasted composing music that won't solve any problems!
- People are starving right now, as another writer dares to write a story that simply tries to entertain the reader.
Everything is political, and we all should keep that in mind. We all have effects on society no matter what. But also, it's fine to make a cromulent thing because it's interesting. We've all only got so much time alive, but you're going to squander the experience if you try to min-max impact on those 90-odd years. People do have to live for themselves sometimes, and this person likes making a neat homebrew OS.
Do you listen to music, read books, have sex etc? I bet you do. And I also bet that you would find it pretty ridiculous if someone asked you why you do those things instead of helping humanity.
I for one celebrate any time people invest their efforts in building something unique, new and interesting. This project is absolutely delightful.