Rust for Linux kernel: the sustainability math for memory-safe systems code

Why the kernel is the one layer where a memory bug is total#

Start with stakes, because they decide everything that follows. A memory bug is not equally dangerous everywhere. Instead its cost depends entirely on where it runs. In a leaf command-line tool a bad pointer crashes one short-lived process, and you restart it. In the kernel the same bad pointer sits in ring 0, with a view of all physical memory.

Because the kernel is the substrate under every workload, its faults are total, not local. A use-after-free in a driver can hand an attacker the whole address space. Therefore the kernel is exactly the layer where the argument for memory safety is strongest. It is also the layer with 30 million lines of C already in place, which is why the trade is not obvious.

The substrate every workload sits on#

Picture the stack as layers of blast radius. The diagram below traces one syscall down from user space into the kernel and out to hardware. On the way it marks where a fault is contained and where a fault is catastrophic.

Read the two dotted edges as the whole argument in miniature. Both point at the same sink. Because the memory manager owns every page and drivers are the biggest attack surface, a single bad pointer in either reaches everything. This is the same substrate that eBPF's shift of logic into the kernel pushes even more work into, which raises the stakes further.

Blast radius: one use-after-free, ring 0#

Consider the plainest kernel bug there is. A driver frees an object, then touches it again on an error path. In user space that is a crash. In the kernel it is a write to memory the allocator may have already handed to something else. Consequently an attacker who controls the timing can steer that write into a privileged structure.

This is why the class matters so much at this layer. The bug is not exotic. However the consequence is maximal, because ring 0 has no outer ring to contain it. So the question is not whether memory safety is nice. Instead it is whether removing this bug class pays for itself over the life of the system.

How big is the memory-safety class, really?#

Before pricing a fix, size the problem honestly. The famous claim is that memory-safety bugs are about 70 percent of serious security defects. However that number is real, and it deserves its caveats. Below are three independent first-party datasets, each landing near two-thirds, and each with an honest limit.

Three first-party datasets that independently land near two-thirds#

No single source proves a universal law. Yet three that were measured separately, by teams with different codebases, agreeing near the same fraction, is strong evidence. Read the caveat column as carefully as the number.

Notice what the caveats do. They stop you overclaiming. Because none of these is the Linux kernel exactly, the honest read is a range, not a constant. Still, the range is consistent, and it is large. Around two-thirds of serious defects come from one class the language can address. For example, you can read the primary numbers at the Chromium memory-safety page.

What "designing it out" looked like in the field#

The Android dataset is the most useful, because it measured a change, not a snapshot. As Google moved new Android code to memory-safe languages including Rust, it tracked the memory-safety share of new-code vulnerabilities year over year. The result is the clearest field evidence we have that the class is designable-out.

Read the mechanism behind the drop. Google did not rewrite the old tree. Instead it wrote new code in memory-safe languages and let the old code age out. Consequently the vulnerability share fell without a mass rewrite. That distinction, new code versus the whole tree, is the exact hinge the cost argument turns on later.

What Rust for Linux kernel code changes at compile time#

Now look at the mechanism, because it is what makes the price so low. Rust removes this bug class with no garbage collector and no runtime tax. The whole cost is paid by the compiler, once, at build time. Below is the exact use-after-free from earlier, in C and then in Rust.

The exact use-after-free the borrow checker rejects#

Compare the two panels line for line. The C version compiles cleanly and ships the bug. The Rust version cannot build at all, because ownership moved the value and the borrow checker refuses a use after the move.

/* A use-after-free the C compiler accepts without a single warning.
   This is the shape of a large share of kernel memory-safety CVEs. */
struct device *dev = acquire_device();

release_device(dev);        /* dev is freed here */

/* ... later, on an error path, or from a second thread ... */
dev->status = STATUS_IDLE;  /* use-after-free: dev points at freed memory.
                               The build succeeds. The bug ships. */

// The same shape in Rust. The borrow checker rejects it at COMPILE time,
// so this code can never build, let alone ship.
let dev = acquire_device();

release_device(dev);         // dev is MOVED into release_device and dropped

dev.status = Status::Idle;   // error[E0382]: borrow of moved value: dev
                             //   value used here after move
                             // The compiler refuses. No runtime, no GC, no cost.

Read the Rust error as the entire value proposition. Because ownership is tracked in the type system, the misuse is a type error, caught before the binary exists. Therefore there is nothing to detect at runtime, nothing to garbage-collect, and nothing to slow down. The safety is structural, and the runtime cost is close to zero. That is the difference between a memory-safe managed runtime and memory-safe native code, and it is the whole reason Rust for Linux kernel work is even plausible.

What safe Rust eliminates vs what stays in unsafe#

Be precise about the boundary, because overclaiming here is dishonest. Safe Rust removes a specific set of bug classes. However Rust also has an unsafe keyword, and kernel code uses it wherever the abstraction has to touch raw hardware. The table decomposes what is covered and what is not.

Read the last two rows as the honest floor. Because unsafe exists, Rust is not a magic wand. Instead it shrinks the trusted, hand-audited surface to the small share of code that truly needs raw access. In practice the goal is a thin, reviewed unsafe core under a large safe surface. That is a real improvement, and it is not the same as zero risk.

Axis 1. Environmental sustainability: the energy tax of the alternative#

Here is the first cost axis most pages miss entirely. Memory safety has more than one implementation. You can buy it with a garbage-collected managed runtime, or with native code and ownership. Because those two routes draw wildly different amounts of energy, the choice has a carbon cost that compounds across a fleet and a decade.

Normalised energy across implementations#

The clearest data here is from a controlled study that ran identical tasks across languages and measured energy. The chart normalises every result to C at 1.00, so the bars read as a multiple of the native baseline. Watch how far a managed runtime sits above native code.

Read the gap as the tax nobody bills. Because Rust holds energy at roughly 1.03 times C, it delivers memory safety at a ~3 percent premium over the fastest native code. In contrast a managed runtime pays 2x to 76x for the same guarantee. So for a driver-class workload, choosing Rust over Java saves about 95 joules per 100, and over Python about 7,485 joules per 100. The full method is in the Energy Efficiency across Programming Languages study. This is the same locality principle behind how the CPU cache hierarchy shapes low-level performance: less waste, closer to the metal, fewer joules.

The crash-and-reboot energy nobody bills#

There is a second energy cost that never shows up in a benchmark. A memory-safety bug in production does not only leak or crash. It also forces recovery. First the node reboots. Then it re-provisions. Meanwhile traffic fails over, and the whole cycle burns energy for zero useful work.

Because designing out a CVE class removes a share of those incidents, it removes their recovery energy too. Still, this cost is real but hard to measure precisely, so treat it as a directional argument, not a headline number. Still, over a decade and a large fleet, avoided reboots are avoided joules. The maintenance axis makes that concrete next.

Axis 2. Maintenance sustainability: patch cycles over a decade#

The second cost axis is labour, and it is the one a finance team actually feels. Every serious memory-safety CVE in a shipped kernel triggers an emergency response. You test a patch, stage it, roll it across the fleet, and verify it. That cycle costs real hours, and it repeats for every bug in the class.

One CVE class removed = N fewer emergency cycles#

Do the arithmetic over the life of the system, not one quarter. A kernel serves for a decade-plus, so the patch cycles accumulate. Because memory-safety bugs are roughly two-thirds of serious kernel CVEs, removing most of that class proportionally removes the emergency cycles they generate. Therefore the saving is not a one-off. Instead it is a recurring cost avoided, every year, for the life of the fleet.

Be careful to price only what is avoidable. Rust does not remove logic bugs, and it does not touch the C that already ships. However it does shrink the single largest CVE class in new code. So the honest claim is narrow and still large. Fewer memory-safety CVEs mean fewer forced patch cycles, and each forced cycle you skip is labour you keep.

Compute it for your fleet#

A worked average is still someone else's fleet. Yours has a specific size, a specific workload, and a specific cost per emergency cycle. So set your own numbers and read the ten-year delta. The instrument computes both axes at once: the maintenance labour designed out, and the energy tax avoided versus a managed runtime. The verdict band flips as you change the workload profile, because where memory safety belongs depends on the blast radius.

Watch the verdict move as you switch the workload. Because a kernel or driver fault is catastrophic, the model recommends adopting there even at a modest fleet size. In contrast a leaf tool sits on the wrong side of the line, since its crashes are cheap to recover from. In practice this is planning math, so measure your own fleet before you commit to a rewrite.

What Rust for Linux kernel support is today (2025 to 2026, no overstatement)#

First, ground the discussion in current reality, not hype. Rust for Linux kernel support is real, in-tree, and shipping drivers, but it is young and still churning. The timeline below traces the arc, with the maintainer-debate inflection marked honestly.

In-tree since 6.1, real drivers, the Asahi GPU#

The mechanism arrived before the drivers did. First the infrastructure merged. Then real hardware followed. The debate about maintenance cost came later, once the churn was concrete.

Read the arc without spin. Because the infrastructure is in-tree and drivers ship on real hardware, the technology is proven. However the ecosystem is still maturing, and the maintenance model is genuinely contested. You can follow the primary sources at rust-for-linux.com and the kernel Rust documentation, and the 6.1 merge is written up in the Linux 6.1 changelog.

The maintainer debate and its real trade-offs#

Take the disagreement seriously, because it is the honest core of the cost side. Rust bindings wrap a C API that keeps moving. Therefore every change on the C side can ripple into the Rust abstractions that depend on it. That is real, recurring work, and reasonable maintainers disagree on who should carry it.

Do not read the debate as a verdict against Rust. Instead read it as a priced cost. Because the churn is real, it belongs in the ledger, not in a footnote. The LWN coverage of the maintainer discussion lays out both sides without cheerleading, which is exactly the register this decision deserves. The Asahi GPU work is documented in the project's own tales of the M1 GPU driver.

The honest cost ledger: what this is NOT free of#

Pair every benefit with its price, or the argument is propaganda. The energy and patch-cycle savings are real. So are the costs below, and pretending otherwise would fail any software engineer reading carefully. The callout names all four honestly.

unsafe blocks, ABI churn, build complexity, human cost#

Read the ledger as the guardrail against false equivalence. Because these costs are concentrated in setup and in maintenance, they favour new code over rewrites, and hot privileged paths over cold leaf ones. That is not a hedge. Instead it is the exact shape of the decision rule this post ends on.

Where memory safety belongs, and where the cost isn't justified#

Bring both axes and the cost ledger into one rule you can act on. The principle is simple. Spend the abstraction cost where a memory bug is catastrophic and the code is new or hot. Skip it where a crash is cheap and the code already ships and works.

A rule you can apply on Monday#

Next, map the rule onto concrete workloads, so it is usable, not abstract. The table gives a verdict per workload shape, matching the interactive ledger above. Read it as a starting point, then price your own case with the calculator.

Notice the pattern across the rows. Memory safety earns its place when the blast radius is large and the code is new or hot. In contrast it does not earn a rewrite of stable code whose crashes are cheap, and it waits where certified toolchains are not ready, as with much real-time firmware. That is the calm, even-handed answer the security-only pages skip. For the layers underneath this decision, it helps to see the full stack a request traverses down to the kernel, and for how this codebase is even maintainable at scale, how the Linux kernel's own Git workflow scaled distributed development. Price your own case, then spend the cost only where the numbers clear the bar.