Yes, and also this old now archived project which had a similar aim: https://github.com/nebulet/nebulet
In Building a unikernel that runs WebAssembly – part 1nebulet
nebulet
Rust2018–2023
nebulet / nebulet · Archived
nebulet
A proof-of-concept microkernel that implements a WebAssembly "usermode" that runs in Ring 0.
21Distinct people
27Mentions
0Explicit recommenders
2.4KGitHub stars
What to know before exploring
What it is
A proof-of-concept microkernel that implements a WebAssembly "usermode" that runs in Ring 0.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2018-04-14 13:19:24 UTC to 2023-10-24 08:40:18 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 13 | 5 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Nebulet
What is Nebulet?
Nebulet is a Google Summer of Code project started during the summer of 2018. More details about Nebulet and GSoC are here.
Under the hood, Nebulet is a microkernel that executes WebAssembly modules in ring 0 and a single address space to increase performance. This allows for low context-switch overhead, syscalls just being function calls, and exotic optimizations that simply would not be possible on conventional operating systems. The WebAssembly is verified, and due to a trick used to optimize out bounds-checking, unable to even represent the act of writing or reading outside its assigned linear memory.
The Cranelift compiler is used to compile WebAssembly to native machine code. Once compiled, there are no complex interactions between the application and the runtime (unlike jit compilers, like v8) to reduce surface area for vulnerabilities.
Right now, Nebulet isn't ready to do anything yet, but it'll get there.
Building & Running
MacOS requires you to first cross compile binutils and to add the newly compiled ld-bfd to your path.
# checkout code and associated submodules
$> git clone https://github.com/nebulet/nebulet.git
$> cd nebulet/ && rustup override set nightly
# install tools
# make sure that `python` is accessible.
$> rustup component add rust-src
$> rustup target add wasm32-unknown-unknown
$> cargo install cargo-xbuild
$> cargo install --git https://github.com/nebulet/bootimage --branch packaging
# build userspace
$> cargo userspace
# compile the kernel
$> bootimage build --release
# compile and run the kernel in qemu
$> bootimage run --release -- -serial stdio
Read the full README on GitHubWhat Hacker News says
27 sourcesWASM could be such an IR unironically https://github.com/nebulet/nebulet. But I doubt that we would be gaining performance/efficiency this way.
In AMD CEO: The Next Challenge Is Energy EfficiencyThis is a super interesting direction. I wrote a wasm OS [0] a few years ago—it didn't go quite that far, but it could've had I spent an additional couple years on it.
[0]: https://github.com/nebulet/nebulet
In Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of Transient ContainersI tried this with nebulet (https://github.com/nebulet/nebulet). Unfortunately the MMU cannot be turned off on modern x86_64 processors.
In SeL4 on RISC-V Verified to Binary CodeExokernels coming back would be so cool.
I wrote a prototype kernel/os [0] a few years back that ran wasm in kernel mode. I'd love to see that idea pursued further.
[0]: https://github.com/nebulet/nebulet
In BPF for storage: an exokernel-inspired approachDepends what you call kernel space
For example, nebulet https://github.com/nebulet/nebulet wanted to run everything in ring 0, but "userspace" was WebAssembly code that had been compiled by "kernelspace" to run sandboxed in ring 0
If a CPU architecture was implemented to only offer ring 0, would a microkernel be impossible? Or would we accept this concept of kernelspace/userspace being implemented in software?
In EBPF is turning the Linux kernel into a microkernelIt's far from comprehensive, but here are a handful of operating system projects that have caught my eye:
[1] MezzanoOS, an OS written in Common Lisp (https://github.com/froggey/Mezzano)
[2] SerenityOS, a Unix-like OS (https://github.com/SerenityOS/serenity/). The primary author has a youtube channel (https://www.youtube.com/c/AndreasKling/)
[3] RedoxOS, a microkernel OS written in Rust (https://www.redox-os.org/)
[4] Nebulet, a microkernel based on webassembly (https://github.com/nebulet/nebulet)
[5] It was never released by Microsoft, but Midori OS had some fascinating ideas like software isolated processes, asynchronous message passing and object capabilities. Nice write-up about the project by Joe Duffy here http://joeduffyblog.com/2015/11/03/blogging-about-midori/
In Learn to write a simple OS kernel with keyboard/screen support (2014)I remember something like that being posted too; I think this is it? https://github.com/nebulet/nebulet
In WebAssembly becomes a W3C RecommendationCould you create an unbounded loop by scheduling another BPF execution on the end of each program? I imagine something like a WASM runtime that would be split into multiple BPF programs on loops. Which would practically achieve https://github.com/nebulet/nebulet, right?
In BPF: A New Type of SoftwareWasm itself doesn’t have any environment functions that would allow things like managing page tables or networking. I think that what you might see is a RISC-V JIT with a ring-0 Wasm runtime compiled to native. Kind of like https://github.com/nebulet/nebulet, probably
In NUVIA: New Server CPU Startup Going After Intel and AMDNebulet [0] was an interesting take on this -- a Rust microkernel compiled to WebAssembly. Unfortunately, the project seems to have run out of steam.
[0] https://github.com/nebulet/nebulet
In Snap: A Microkernel Approach to Host NetworkingThis sounds great. Basically the web created a cross platform & sandboxed API to access everything we need (Camera, Sensors, OpenGl through WebGl, etc.) but it was very opinionated (for historical reasons) as it imposes the slow JS, the DOM, CSS/HTML etc.
Now this is the same idea but, this time, one layer lower so that we can have performance, the language we want, etc. This is kind what I always wished would happen.
It will be interesting to see how the sandboxing will work with already existing sandboxing solutions. For e.g a WebAssembly app packaged as a Android/Flatpak/UWP/etc. , there will be the need to make mappings between the permissions of the two sandbox systems. Or even maybe one day we'll have the Webassembly sandbox as the only sandbox (like in https://github.com/nebulet/nebulet)
In Standardizing WASI: A system interface to run WebAssembly outside the web> use WASM outside the browser (I don't even know if that's a thing)
Not mainstream, but absolutely a thing. There's people even looking at running it in Ring 0.
https://github.com/nebulet/nebulet
In Universal Binaries Using WASMThanks for the detailed reply!
I don't like the traditional GRUB approach because it leaves so much work for the kernel (assembly entry point, stack setup, creation of new page tables, etc). Why not treat the kernel like any normal application and load it like a normal ELF loader? This has the following advantages:
- Each loadable program segment is mapped at its specified virtual address. To create a higher-half kernel, just set the desired virtual address in your linker script. If you don't need a higher-half kernel yet, simply use the default linker script. This is what we do at the moment since we don't have any userspace yet. Like in normal applications, the specified physical addresses do not matter.
- There's no assembly code required at the entry point. You can start directly in Rust because there's already a stack and everything
Read the rest
lives at its expected address.
- Less startup overhead, since the page tables are only set up once in the bootloader. With the GRUB approach, the kernel needs to recreate the page tables since GRUB only created rudimentary mappings.
Like you said, the disadvantage is that the kernel doesn't know its physical addresses. But it can still find them out by traversing the page tables.
Overall, I think it's worth it because it makes the startup process much easier from the kernel's perspective. I believe that this is especially important for a teaching project because readers shouldn't have to understand assembly, linker scripts, virtual/physical addresses, higher half kernels, and page tables before they can even boot their Rust kernel. For people that don't like the bootloader's decisions we can add more configuration options or they can use a custom version of the bootloader (e.g. the nebulet project does this [1]).
[1]: https://github.com/nebulet/nebulet/blob/c0f3c993a87e72a95f85...
https://github.com/nebulet/nebulet
"Nebulet is a microkernel that executes WebAssembly modules in ring 0 and a single address space to increase performance. This allows for low context-switch overhead, syscalls just being function calls, and exotic optimizations that simply would not be possible on conventional operating systems. The WebAssembly is verified, and due to a trick used to optimize out bounds-checking, unable to even represent the act of writing or reading outside its assigned linear memory."
In Redox – A Unix-Like Operating System Written in RustShowing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.