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.
How is the performance when using fuel with wasmi?
We are considering to use epoch counter, but for now we just turned fuel off.
In past experiments I remember that fuel metering adds roughly 5-10% overhead to Wasmi executions. The trick is to not bump or decrease a counter for every single executed instruction but instead to group instructions together in so-called basic blocks and bump a counter for the whole group of instructions.
This is also the approach that is implemented by certain Wasm tools to add fuel metering to an existing Wasm binary.
What's the rationale? Just preventing infinite loops from hanging the host?
If the inefficiency is the counter, what if you just calculated an instruction offset - start < threshold every once in a while?
This probably makes no sense, ignore it, I'm way in over my head.
[1] https://github.com/bytecodealliance/wasmtime/issues/4109
[2] https://github.com/bytecodealliance/wasmtime/blob/main/examp...
There is a variety of ways to implement fuel metering with varying trade-offs, e.g. performance, determinism and precision.
In this comment I roughly described how Wasmi implements its fuel metering: https://news.ycombinator.com/item?id=44229953
Wasmi's design focuses on performance and determinism but isn't as precise since instructions are always considered as group.
I’m not sure what it’s used for in this context or how instructions are weighted
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.
No, because each reflection comes at a cost (some light transformed to heat)
"Why do people mainly marry and make friends with people who look extraordinarily similar to themselves?"
To not get so much surprises and have a more stable life. (I didn't choose that path.)
(But I feel it would be too much OT answering the other questions and don't want to distract from this great submission or the interesting Wasmi concept)
A few notes: * There's no such thing as "absolute hot" state that meansno more heat can be added * Blackbody radiation means that above a certain temperature, regardless of what you make your mirror out of, it will be spontaneously emitting visible light at all times.
https://de.wikipedia.org/wiki/Perpetuum_mobile
Same principle.
Basically, what you propose negates the nature of reality. There is always friction/energy loss into heat (increased chaotic movement). Only way to deal with it, if you want permanent cycles, is constantly add energy in the same amount that is lost.
Not currently. There's an accepted proposal, but its in progress.
> 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.
That's what I did with my last hackintosh attempt and it works pretty well. The downside: without real GPU events to respond to, you'd be stuck with whatever resolution Linux decided upon in whatever screen configuration Linux decided to boot.
If this thing can run as a UEFI executable rather than a real OS, you might be able to use the UEFI video drivers to get video working relatively easily without having virtio graphics, but I'm not sure if it's even possible to pull that off while doing real OS things.
I am skeptical that the UEFI drivers would be up to the job. I worked on EDK2 drivers many many years ago and things were not really optimised for speed. Mostly we just did the simplest thing that would boot Linux without any unnecessary delays.
Plus they are very often gonna be buggy and there's not much you can do about buggy UEFI FW.
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!
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.
https://www.siberoloji.com/understanding-microsoft-midori-th...
Still, very impressive project!
What's the threat model exactly? As far as I can tell all the apps are compiled directly into the kernel, and the web browser doesn't run JavaScript. So I don't see any way to get untrusted code into the thing.
1. To isolate processes - physical memory used by one process is only mapped into that process's virtual memory space. No other processes can read it. (Except for shared memory.). Using WASMs isolation instead means you don't need this so much (ignoring Spectre) but you still need...
2. To handle memory fragmentation - each process expects to see a contiguous block of memory available to it (more or less). Especially in WASM, you just get a big linear memory array that you can grow and shrink as you like.
If these blocks have to be physically contiguous blocks in memory it's going to be really hard to organise them, especially because you don't know how much memory they use in advance.
For example you run two apps and they initially say they need 100MB each. So you allocate app A at [0, 100MB) and app B at [100, 200MB). How app A says "I need 1 extra MB please!". Well since you don't have virtual memory that has to be at the physical address 100MB, which is already occupied by app B. So you have a few bad options:
* Leave space between apps in case they want to grow. But it's not obvious how much space, and also this would be extremely inefficient since you're literally wasting physical RAM.
* Don't allow apps to grow their memory. I think the very first versions of WASM didn't support this. Again this is obviously inefficient because apps have to allocate enough memory for their maximum memory usage even if they rarely use that.
* Shuffle apps around in physical memory when you need some space. I think this is possible but it would be really slow and lead to weird random pauses while GBs of memory is copied.
Virtual memory solves those issues. I think you could probably still build a system with these limitations for some use cases, e.g. kiosk/Point of Sale terminals. But for general purpose use it seems impossible unless I've missed some trick...
Besides, why would you design around the lack of a MMU? Even in embedded space it's often there.
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
[1] https://sdegutis.github.io/blog/dear-everyone-hire-me-to-mak...
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!
I guess not much can be done at the moment: dependencies are often the primary obstacle in porting crates to new targets, and just comparing the list of dependencies of wasmtime vs wasmi gives a pretty good indication of which crate is a bit more careful in this regard:
https://crates.io/crates/wasmtime/33.0.0/dependencies https://crates.io/crates/wasmi/0.47.0/dependencies
That's great to hear! I think it is a bit too early to spend extra effort on porting Wasmtime to Motor OS at the moment, as there are a couple of more pressing issues to sort out (e.g. FS performance is not yet where it should be), but in a couple of months I may reach out!
What are the min memory requirements for wasmtime/cranelift?
I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.
https://github.com/bytecodealliance/wasmtime/blob/main/pulle...
However, execution is just one metric that might be of importance.
For example, Wasmi's lazy startup time is much better (~100-1000x) since it does not have to produce machine code. This can result in cases where Wasmi is done executing while Wasmtime is still generating machine code.
Old post with some measurements: https://wasmi-labs.github.io/blog/posts/wasmi-v0.32/
Always benchmark and choose the best tool for your usage pattern.
I guess it's like v8 compared to quickjs.
Anyway all this talk about wasm makes me want to write a scriptable Rust app!
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.
I'd like to see an Inferno with a WASM runtime that utilizes a Plan 9 like ABI/API instead of WASI. Node9 did similar but with Lua: https://github.com/jvburnes/node9
SPECTRE and MELTDOWN enter the chat
You can see a snippet of it running (and rendering Hacker News) in the demo video.
I think we need a cleaner split between the content web and the app web. The content web should need a minimal HTTP client and HTML parser. Web apps could actually run on something quite similar to this OS here: wasm + some GUI plumbing 5-10 hardware APIs for the most common things. Please just make sure it has UDP.
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.
I don’t mean this in a hostile way, however, it has become frustrating finding this predictable and low effort comment from you every time I open an HN thread on WebAssembly — and, frankly, I’ve begun collapsing comments whenever I see your username.
Every iteration on the concept brings different approaches and tradeoffs made from lessons learned from previous attempts. This is just how engineering, and our industry, works.
I don’t mean disrespect. I assume you are probably speaking from a place of experience. I would be so much more interested hearing your thoughts on the minutiae than basic pattern recognition.
Here is tip for you as well, learn from the past, before doing any kind of WebAssembly marketing of how innovative it happens to be, versus JVM as if there was never anything else done.
wasm is likely to be that thing for the simple reason that it actually pursues this goal. JVM notionally does (or did? what does Oracle say these days?), but its bytecode is so much more high-level that it's not even in the same ballpark.
Android could have used anything and it would have been successful, even C++.
These were both successful purely because they're cheap, not because technology.
Great technology sadly wins on merit.
Technology wins on either being cheaply available, in a worse is better fashion, as devs rather drink free lemon juice instead of nice costly orange one, or by having companies with willingness and deep pockets to push it no matter what.
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?
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
This is maybe more of a philosophical answer, but IMO the answer is to play games with people you trust. I've recently redicovered the joy of LAN parties (both Halo and AoE2) and man, it's so much better than the countless hours I spent getting pissed at faceless strangers in online games.
I wish there were more games designed for local multiplayer.
Anticheat is an attempt to control the behavior of the community. Your solution is to just control who is in your community.
In a way, I think it's the same lessons learned from social networks. You see it in the trends moving away from global communities back toward smaller online communities; private Discord servers, BlueSky follow/block lists, and so on.
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.
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.
While working at DreamWorks, I would often watch artists navigate complex marking menu hierarchies and invoke a command before the menu items themselves could actually be read by a non-trained user. In our custom lighting tool, you could execute the marking menu command by invoking the menu command and making them mouse movement before the menu actually drew.
1. https://www.billbuxton.com/MMUserLearn.html 2. https://damassets.autodesk.net/content/dam/autodesk/research...
https://www.gamerguides.com/assets/guides/192/neverwinter_ni...
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.
