The Rust-for-Linux debate is the wrong question.
Most of the conversation about Rust in operating systems goes in one of two directions. Either it's about Linux specifically — whether the upstream community accepts Rust drivers, who maintains them, whether someone resigned from the maintainership over the politics. (As of April 2026, the Linux memory management subsystem lost its sole maintainer of 26 years — Andrew Morton stepped down, and two weeks later the community gathered at a developer summit unable to name a replacement. Memory management CVEs were nearly 20% of all Linux kernel security issues between 2020 and 2024. No notes.) Or it's about kernels optimized for domains that aren't general-purpose cloud workloads: seL4 is formally verified and runs in production on embedded DoD systems — genuinely impressive work — but it's not what you reach for when you want to run PostgreSQL on a VM.
The framing both sides accept: if you want a memory-safe kernel, you have to either replace Linux or build a research artifact.
I picked a different framing. What if we don't try to replace Linux at all?
The scope-reduction trick
Linux works because it runs on every piece of hardware anyone has made in the last thirty years. Roughly thirty-eight million lines of code, the vast majority of which is drivers — kernel modules that know how to talk to a specific network card, a specific GPU, a specific Bluetooth chipset. The driver problem is the reason "rewrite Linux in a memory-safe language" is laughably hard. You don't just need to replace the kernel core; you need to replace all of that hardware support too.
But the workloads I actually care about — confidential-computing enclaves, cloud VMs, container hosts — don't have any of that hardware. They run on virtualized hardware: virtio devices, the hypervisor's emulated APIC, the hypervisor's clock. The driver surface for a VM-only kernel is tiny. Six device types — virtio-blk, virtio-net, virtio-rng, virtio-gpu, virtio-input, virtio-sound — and you've covered every workload that's relevant for the markets I want to be in.
The scope reduction is dramatic. From ~38 million lines of Linux to roughly 150–250 thousand lines of Rust to do the same job for the workloads anyone actually deploys on confidential-computing infrastructure.
That's tractable. That's a one-person project, run patiently over weekends and stretches of focused calendar time. That's something that I think I can actually finish, instead of an academic project that boots a hello-world in QEMU and dies.
I want to be clear about what this is and isn't. This is not "Rust Linux." I am not trying to replace Linux. Not yet ;). Linux is a miracle of engineering built by thousands of people over thirty years, and I have gained enormous respect for it through this process. What I'm building is a kernel that speaks Linux ABI for the workloads I actually care about — specifically so real Linux software doesn't need to change. Same binaries. Different kernel underneath.
Is it done? No. Does it run real things? We'll get to that.
Why Rust? (For everyone who's never had to care before)
I'm a C programmer. I've shot myself in the foot more times than I can count, healed most of those wounds, and kept going. C and I have an understanding.
Here's the thing about C: it hands you a loaded gun and trusts you completely. Null pointers, dangling pointers, buffer overflows, use-after-free — none of these are bugs in C per se. They're just you doing something C politely allowed you to do. The language has no concept of "this pointer is no longer valid." It trusts you. You, specifically. At 2am. On a Friday.
Rust doesn't trust you. And I mean that as a compliment.
For code that doesn't use the unsafe keyword, Rust's type system makes an entire category of bugs impossible to express. A use-after-free in safe Rust doesn't compile. Not "compiles with a warning." Not "lint will catch it." It doesn't compile. The foot gun still exists — but you have to explicitly reach for it and sign your name on it first.
For a normal application that's a nice property. For a kernel — where there's nothing underneath you, no OS to catch your mistakes, no segfault handler because you are the segfault handler — that's the whole game.
The class of memory bugs that dominates Linux CVEs? Use-after-free. Buffer overflow. Null deref. Data races. These aren't exotic vulnerabilities. These are the ones in OpenSSL, in the Linux kernel, in your router firmware. They exist because C lets them exist. In safe Rust: structurally impossible. The compiler just won't let you.
Here's the second thing: unsafe is auditable.
C is 100% unsafe all the time. You can't grep for "the dangerous parts" because every line is potentially the dangerous parts. In Rust, if a piece of code needs to step outside the safety guarantees — raw pointer arithmetic, talking directly to hardware, something the type system can't verify — the programmer has to write the word unsafe. Explicitly. Every single time.
That means every place the guarantees are relaxed is visible. You can find them all. You can review exactly that code. For a security engineer, that's not a small thing — the question isn't "is there unsafe code in this kernel?" Of course there is, there has to be. The question is "can I find all of it?" In Rust: yes.
No more accidental foot guns. Only intentional ones.
There's one more thing Rust gets you that I haven't mentioned yet — it's a full post by itself. Short version: Rust's type system enables verification methods that simply don't exist for C code. We'll get there.
What you don't get is bare-metal hardware support. No drivers for your specific network card, your specific GPU, your specific RAID controller. You get virtio. That's the trade.
Why this works as a strategy
The prevailing assumption — "if you want a memory-safe kernel for production, you'll wait years and millions of person-hours" — quietly assumes that "the kernel" means "Linux." It doesn't. For the workloads that matter on cloud and confidential-computing infrastructure, the kernel is just the piece of software that sits between the hypervisor and the application. Replace it with one that's better.
The argument for memory safety in foundational systems software is not subtle. The NSA's published case for memory-safe languages explicitly cited C and C++ as deprecated for new foundational software. CISA's "Secure by Design" guidance says the same. Federal procurement is increasingly requiring memory-safety claims on the software it buys. And the workloads doing this — the cloud confidential-computing platforms, the federal-side encrypted workloads — all run in VMs.
The intersection of "this scope is tractable" and "this property is in demand right now" is where the project sits.
So — did we rewrite Linux?
Kind of. Yeah.
Not 38 million lines. Not the driver stack. Not 30 years of hardware quirks. But the core of what a kernel does for modern cloud workloads — process management, memory, syscalls, signals, ELF loading — we wrote that. In Rust. From scratch.
We didn't replace Linux. We wrote a kernel that speaks its language.
But here's the honest part: Rust doesn't get you all the way there.
A kernel has to touch real hardware. Map memory. Manage page tables. There will always be code that has to step outside Rust's safety guarantees — code where the compiler can't hold your hand because you're operating below the level where the rules apply.
The question isn't how to eliminate that code. You can't. The question is how you contain it — how you build a structure where the unsafe parts are small, isolated, and auditable, and the rest of the kernel provably can't reach them.
That's the next post.