Show HN: Munal OS: a graphical experimental OS with WASM sandboxing

> Every iteration of the loop polls the network and input drivers, draws the desktop interface, runs one step of each active WASM application, and flushes the GPU framebuffer.

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...

Pretty cool!

> The reliance on VirtIO means Munal OS does not support running on real hardware yet

I think if you wanted to run it on HW, instead of running adding drivers to it a cool strategy would be to build a Linux-based system that acts as a bootloader and then starts a minimal hypervisor. Then you could keep the "virtio is the platform" thing.

It would be quite cool how you end up using VirtIO as the platform for the OS in the same way that you use WASM as the platform for applications.

For what it's worth, as a platform security nerd, unfortunately I do think we need to use the MMU. But, a cool realisation with your design is that it doesn't mean we need virtual memory, you could keep the identity mapping and just use the protection bits. Unfortunately that still takes away a big part of your simplification since now you need multiple set of pagetables, need to manage TLB flushes, etc.

> The downside of course is that each step of the loop is not allowed to hold the CPU for arbitrary amounts of time, and must explicitly yield for long-running tasks.

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 to ask, were you influenced at all by the talk “The Birth and Death of Javascript” from Pycon 2014?

https://www.destroyallsoftware.com/talks/the-birth-and-death...

It describes a hypothetical future where operating systems use asm.js (precursor to wasm) sandboxes as an alternative to virtual memory protection. I always thought it was a cool idea, and it seems to be a key part of your design.

Apart from the cooperative scheduling, I think Spectre probably kills the security model, and I can't understand how this could work efficiently without virtual memory. How do you implement `memory.grow`? Do you have to `memmove` an entire app's memory when it wants to grow by 10 kB and another app is in the way? Is that even possible?

Still, very impressive project!

I can't wait to see what attempts like this might look like after wasm components start becoming real(-er).

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

This is incredible. I wonder if this will be the future of OSes.

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.

Wow, this thing even has its own web browser! https://github.com/Askannz/munal-os/tree/master/wasm_apps/we...

You can see a snippet of it running (and rendering Hacker News) in the demo video.

/rant mode on

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.

Incredible that it's a client OS! I think this kind of design can have immediate use server-side because it eliminates quite a bit of security boundary by making the kernel much smaller and eliminating all other libraries and applications besides the thing you are running. I think a key/value store for example would be an excellent candidate to run like this.

Is it possible to achieve decent network performance with this IO model? Can it play any tricks with memory to eliminate some of the copies required when hosting WASM in most programs?

This is just so inspirational and cool. I’ve had so many of these concepts floating around in my head, without the critically necessary capability, or followthrough. I’m sure others have as well. It’s very cool to see someone execute on it.

I wonder about operating systems with isolated applications like this providing some kind of attestation.

Is it even possible to do that in a non-user hostile way?

The use case I daydream about is online competitive gaming. It’s a situation where a majority of users are willing to give up software freedom for a fair community. Consoles used to be a locked down way to guarantee other users were participating fairly, but this increasingly less the case as cheaters become more advanced. Solving this problem necessarily locks down access to software and hardware, as far as I can figure it. From a game theory perspective I can’t see any other approach. Enter “kernel level anticheat”; aka rootkits, depending on who you ask.

So I guess I wonder if virtualization at a level like this can somehow be a part of the solution while preserving software freedom, user privacy and security where the user still wants it

Fun project. The grey beards will gladly read how is it qualitatively different from early Windows or maybe even AmigaOS Workbench? The dinosaurs will probably point to bytecode interpreters mixed with OSes like Lisp machines or smalltalk environments, could be an interesting comparison, too.

Not an export in OS. Can op explain the project motivation and high-level design a bit? The readme file seems to be a feature introduction and barely touches the motivations, i.e., what problem does it aim to solve, is it designed for any specific domain or it's a general purpose OS, what gain could those feature bring in practice?

> It's an unikernel design that is compiled as a single EFI binary and does not use virtual address spaces for process isolation.

Are you able to quantify what kind of performance improvement to expect from such a design?

My understanding is that this can completely skip overhead of syscalls and TLB, but I have no idea of how much performance benefits can it result in practice.

Great work. I've always wondered if WASM could actually be used as a more generic alternative alternative to eBPF where you could actually do more complex logic than the average eBPF program at the kernel level and still have customized and restricted access to the kernel APIs and data structures like you're actually developing a typical kernel module.

The radial menu is brilliant.

It is reminiscent of how basic team communication works in StarCraft 2. You alt-click to ping the minimap (draw allies' attention to something in that general area). If it's something more specific, you can hold alt, and drag-click to open a directional menu, from which you can choose one of four orders: attack, defend, retreat, and OMW. Some pings are also context-sensitive: click on the minerals/gas to say "I want to gather these resources", useful for establishing expansion patterns, strategy in the early game (macro/rush), tech transitions (ping your hydralisk den to say "I'm gonna make hydras"). All of this is key in a game with hundreds of APM and split-second reaction times.

It's a similar story with GUI actions. Power users appreciate good key shortcuts more than almost anything. If you do something thousands of times a day, it needs to be near-instant. The mouse is often disregarded, and IMHO that's because nobody is really doing any serious research in that area. Radial menus pack a lot of actions (where three mouse buttons fall short), exploit Fitt's law, muscle memory, etc. They are also discoverable and provide immediate visual feedback (contrary how "mouse gestures" work in some applications).

Couple notes on the current implementation (from what I've gathered from the video):

- Settle on how many actions *at most* do you want available in the menu (4? 6? 8?), divide the menu accordingly, and display those divisions regardless of whether there's an actionable item. This will help develop muscle memory. If you need more than say 8 actions, the menu might already be getting more crammed than you'd find useful.

- When figuring out where to place stuff, I would suggest prioritising the four cardinal directions for the most common actions, starting with the horizontal positions. "Surprising" or destructive actions (even if un-doable) should be placed at the harder-to-reach positions.

- Keep the actions as consistent as possible between different contexts, e.g. left on the document closes the document, left on the title bar closes the window, but not: left on an icon deletes the file.

Questions worth considering:

- I'm not sure if a launcher is a good use for this model; once you have a dozen apps (or more than 3-4 windows to switch between), it's gonna get awkward. Maybe a more traditional list-menu, and/or a dock? But I'd be intrigued if you come up with something original.

- What happens when you open a menu too close to the screen edge? It's an interesting case to consider. Warping the pointer might be an option (the physical mouse can keep moving, after all).

- Is this going to work well with a trackpad? Maybe use a two/three finger swipe, but that depends on how precise is your hardware.

- What about a trackpoint, or die-hard keyboard users? Perhaps you can trigger the menu by holding down the space key?

Anyway, this is really inspiring.

This is amazing. Congrats on the project! I initially started learning rust a few years ago specifically for it's support for compiling to webassembly, as I found it so interesting. This project and the discussion on the post makes me want to get back to it :D

this is very impressive. I really like that you have a browser which is almost mandatory for a desktop OS now. You should write down your TODO list and I hope you keep working on this. I think there is room for many OSes especially ones written in Rust.

This is a very good bucking of conventional wisdom. Good job!

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.

This is so interesting!

Great job! Congrats on shipping, this looks like a big project

Very cool. This project needs something like a native control library interface into the wasm apps so that there can be UX uniformity.

Once wasm wasi runtime for exaequOS is ready (I hope soon) I will have a look for running munal OS app in the browser

Reminds me of project mempo from like 10 years ago

[flagged]