Rust in Kernel and Embedded Stacks: When Does It Make Sense?

Rust in the Linux kernel stopped being a question of principle some time ago. It is now a practical question about versions and toolchains. At the Maintainers Summit in December 2025, the kernel developers reviewed the experiment that began in 2021 and declared it a success: Rust is no longer experimental, and the kernel now has three core languages instead of two.

That announcement produced a great deal of writing about whether Rust is good. This article does not argue that. It answers a narrower and more useful question: for the product you are building right now, on the silicon you have already chosen, does Rust make sense — yes or no? The answer turns out to be decidable, and it usually does not depend on your opinion of the language at all.

What actually changed, with dates

The facts below were read from the kernel tree and from the report of the December 2025 Maintainers Summit session led by Miguel Ojeda. They are worth stating precisely, because most summaries of them are vague.

• Rust is no longer experimental. After nearly five years, the maintainers agreed the experiment had succeeded. Rust is a supported kernel language.
• Rust code is already running on millions of devices. Android 16 systems on the 6.12 kernel ship the Rust ashmem module. This is production use, not a trial.
• The Android binder driver, written in Rust, was merged for 6.18.
• The volume of Rust in the tree grew by a factor of five in one year.
• The toolchain floor is now real and specific. Mainline Documentation/process/changes.rst lists Rust 1.85.0 and bindgen 0.71.1 as minimum versions. The plan is to track whatever Rust version Debian stable ships, raising the minimum six to twelve months after each Debian release.
• Architecture support is good but not universal. x86, Arm, RISC-V, LoongArch and user-mode Linux are in good shape. PowerPC has support. s390 was described as probably working but unconfirmed, and some drivers are unlikely to behave on big-endian systems.

And the one that matters most for embedded work: David Airlie, the DRM maintainer, said the graphics subsystem is about a year away from refusing new drivers written in C. Not rewriting the existing ones — requiring Rust for new ones. If your product roadmap includes a display or GPU driver you have not written yet, that sentence is a planning input, not a debate.

The question that actually decides it: which kernel does your BSP pin?

Here is the part that most Rust articles skip, and it is the part that settles the matter for the majority of readers.

You cannot write a Rust driver on its own. You write it against the Rust abstractions for the subsystem you are touching — the safe wrappers around the C interfaces for platform devices, PHYs, DRM, misc devices, and so on. Those abstractions are kernel code. They landed in specific kernel versions, and they are not backported to your vendor’s fork.

That is not a claim you have to take on trust. It is two directory listings, and you can reproduce them in a minute.

Mainline’s rust/kernel directory today contains 104 entries. Among them: drm, gpu, net, pci, platform.rs, i2c.rs, clk.rs, dma.rs, irq, iommu, regulator.rs, pwm.rs, usb.rs, miscdevice.rs. That is the vocabulary a driver is written in.

Now the same directory on Rockchip’s develop-6.1 — the branch a great many RK3588 products are built from:

raghu@techveda.org:~$ git ls-tree --name-only origin/develop-6.1 rust/kernel/
rust/kernel/allocator.rs
rust/kernel/error.rs
rust/kernel/lib.rs
rust/kernel/prelude.rs
rust/kernel/print.rs
rust/kernel/str.rs

Six files. Not one of them is a device, a bus or a subsystem abstraction. You can print a message, allocate memory, handle an error and build a string. You cannot write a driver, because there is nothing to write it against. The rust/ directory is present — inherited when the vendor forked 6.1 — and it is empty of everything that matters.

So the practical question is not “should we use Rust?” It is: does the kernel we actually build contain the abstractions for the subsystem we need? For most product teams, the answer is decided by a branch name their silicon vendor chose years ago.

These are the kernels the 17 SoCs on our BSP Tracker are pinned to today:

Read that table as a decision, not as trivia. If your product runs Rockchip’s develop-6.1 or Allwinner’s 5.15 tree, Rust is not available to you this year — regardless of what your team thinks of it. You could carry the abstractions yourself, out of tree, on a vendor fork nobody else is testing. That is not adopting Rust. That is adopting a second maintenance burden on top of the one you already have.

If, on the other hand, you are on NXP’s lf-6.18.y or TI’s ti-linux-6.18.y, the question becomes real and the rest of this article is for you.

Where Rust makes sense today

1. A new leaf driver, on a recent kernel, in a subsystem that already has abstractions

This is the clearest case, and it is deliberately narrow. A leaf driver — one that sits at the edge of the tree and is not a dependency of the core — written fresh, on 6.12 or newer, in a subsystem where somebody has already done the abstraction work.

The reference example is small enough to read in full. The Rust version of the ASIX network PHY driver, drivers/net/phy/ax88796b_rust.rs, merged in v6.8-rc1, is a single file well under 150 lines. It is functionally equivalent to the C driver, which remains the default; the Rust one is selected with CONFIG_AX88796B_RUST_PHY. It exists so that engineers can read the two side by side, and it is the best first thing to read on this subject.

raghu@techveda.org:~$ ls drivers/net/phy/ax88796b*
drivers/net/phy/ax88796b.c
drivers/net/phy/ax88796b_rust.rs

raghu@techveda.org:~$ grep -rn "AX88796B_RUST_PHY" drivers/net/phy/Kconfig
# a Kconfig switch, not a replacement: the C driver is still the default

Graphics is the subsystem moving fastest. Nova, the Rust successor to Nouveau for NVIDIA GPUs, has pieces merged into mainline. Tyr, a Rust driver for Arm Mali CSF GPUs and a port of Panthor, is a joint effort by Collabora, Arm and Google. Given the DRM maintainer’s stated direction, a display or GPU driver you start in 2027 is likely to be written in Rust whether or not you planned it that way.

2. Code that parses input you do not control

Memory safety is worth most where the input is controlled by someone else. The first place to spend it is any code that reads bytes an attacker can choose.

We wrote recently about six flaws in U-Boot’s verified boot, and every one of them lived in the image parser that runs before the signature check. Two of them came from a single unchecked return value: a NULL pointer and a negative length, both used without validation. That specific class of bug — the one where a length is trusted and a pointer is not checked — is the class Rust removes by construction.

Note carefully what that does not mean. Rust would not have prevented the underlying design error of parsing before verifying. It removes memory-safety bugs, not logic bugs, and the distinction matters when you are deciding where to spend effort.

3. Safety-critical work — but with a qualified toolchain, which is a different thing

This is the most commonly confused point in the whole subject, so it is worth being exact.

The Rust in the Linux kernel is compiled by upstream rustc. It is not a qualified toolchain and it carries no safety certification. If you are building to ISO 26262, IEC 61508 or IEC 62304, the relevant thing is Ferrocene, the Rust toolchain qualified by TÜV SÜD for ISO 26262 (ASIL D), IEC 61508 (SIL 3) and IEC 62304 (Class C). Ferrocene 26.02.0, shown at embedded world 2026, added a certified subset of the Rust core library, increasing the number of certified functions from 2,903 to 5,169.

4. Bare metal, where the choice is genuinely yours

Outside the kernel, on the microcontroller side of an embedded product, none of the constraints above apply. There is no vendor BSP pinning your kernel, because there is no kernel. If you have a new bare-metal or RTOS-side component to write, the decision is a straightforward one about your team’s skills and your toolchain, and Rust is a reasonable choice on any target its compiler backend supports.

Where Rust does not make sense

Your BSP is pinned to an old kernel. Covered above, and it is the most common situation. Fix the kernel question first. Rust depends on the answer.

You want to rewrite a working C driver. The kernel is not asking for this, no maintainer will thank you for it, and you will be trading a tested driver for an untested one to gain a property the tested one was not failing on.

Nobody on the team can review Rust. This one is underrated. A driver that one engineer can write and no colleague can review is a liability, not an asset — and it is worse than the C driver it replaced, because only one person in the building can maintain it. The constraint is review capacity, not writing capacity.

Your architecture is outside the well-supported set. If you are on s390, on a big-endian target, or on an architecture without a working LLVM backend, this is not your year. Work on GCC-based Rust front ends is progressing — gccrs can now compile the kernel’s Rust code, though producing correct runnable output is still being worked on — but progressing is not the same as available.

You are hoping Rust satisfies a compliance requirement. Memory safety is becoming a procurement question, and the Cyber Resilience Act’s obligations begin to apply from 11 September 2026. But “we are adopting Rust” is not a vulnerability-handling process, an SBOM, or an update path. It is an engineering choice that may improve your position. It is not a substitute for the work.

What it costs, honestly

Every article that recommends Rust should be willing to state what it costs. These are the costs.

• Toolchain and CI. rustc 1.85.0 or newer, bindgen 0.71.1, and an LLVM-capable build. Your vendor’s BSP build system almost certainly does not have these switched on today.
• unsafe at the boundary. Every call into C is unsafe by definition. Rust confines the danger; it does not delete it. Someone still has to reason about those blocks.
• Abstractions you may have to write yourself. If the subsystem you need has no Rust abstraction upstream, writing one is a real upstream project, with review, iteration and a maintainer’s opinion attached.
• Your silicon vendor will not support it. This is the cost teams forget. A Rust driver in your product is a driver your vendor’s support contract does not cover, on a tree they do not test. You own it, entirely, for the life of the product.
• Review capacity. See above. It is the limiting factor for most teams, and it takes the longest to build.

The checklist: does Rust make sense for your product?

Answer these in order. The first “no” that stops you is your answer, and you do not need to reach the end.

Most teams reading this honestly will stop at question 1. That is not a failure of the language. It is a fact about the tree their product is built on — and it is the same fact that decides when their security fixes stop arriving.

What to do this quarter

Three things, none of which require a decision from anybody above you.

Find out which kernel you actually ship. Not the one in the vendor’s release notes — the one in your build. Then find the date its upstream fixes stop. If that date is inside your product’s support window, you have a larger problem than Rust, and you should solve it first.

Have one engineer write one small driver in Rust, on mainline, on real hardware. Not a rewrite of anything you ship. The ASIX PHY driver exists specifically as a reference and is short enough to read in full. The goal is not the driver. The goal is a team that can review Rust in eighteen months, when the DRM decision has landed and it is no longer optional.

Put the question on the agenda for your next silicon selection. “Which kernel will this vendor’s BSP be on when we ship, and what will it support?” is now a hardware decision, not a software one — and it is one you cannot revisit after the schematic is frozen.

Key takeaways

• The kernel Rust experiment ended in December 2025. Rust is now a core kernel language alongside C and assembly, and Android already ships Rust kernel code on millions of devices running 6.12.
• For a product team, the deciding factor is not the language but the kernel their vendor BSP pins. Rust abstractions live in recent kernels and are not backported to vendor forks.
• The realistic floor today is 6.12, and the practical answer is 6.18. On 5.15 or 6.1 — where a large share of shipping products sit — Rust is not an option this year.
• Rust is for new code. No maintainer is asking anyone to rewrite a working C driver, and doing so trades a tested driver for an untested one.
• The DRM subsystem is roughly a year from refusing new drivers written in C. Any display or GPU driver still ahead of you should be planned on that basis.
• Kernel Rust is not certified Rust. Safety work needs a qualified toolchain such as Ferrocene, which is a separate decision.
• The limiting factor for most teams is review capacity, and the forgotten cost is that your silicon vendor will not support a Rust driver in your product.

Frequently asked questions

Is Rust now required to write Linux kernel drivers?
No. Rust is a supported language, not a mandatory one, and the vast majority of the kernel remains C. The one place a requirement is coming is graphics: the DRM maintainer has said the subsystem is about a year away from refusing new drivers written in C. Existing C drivers are not affected.

Our BSP is on Linux 6.1. Can we still write a Rust driver?
Not in any way you would want to support. The build plumbing exists from 6.1, but the Rust abstractions for the subsystem you need almost certainly do not, and they are not backported into vendor forks. You would have to carry those abstractions yourself, out of tree, on a kernel nobody else is testing them against. The realistic answer is to fix the kernel question first.

Does using Rust help with ISO 26262 or the Cyber Resilience Act?
They are different questions. For functional safety you need a qualified toolchain — Ferrocene is qualified by TÜV SÜD for ISO 26262 ASIL D, IEC 61508 SIL 3 and IEC 62304 Class C — and that is not the compiler building the Linux kernel. For the CRA, memory safety may strengthen your position, but the obligations that begin on 11 September 2026 are about vulnerability handling, reporting and delivering updates. Adopting a language is not a substitute for any of that.

Will Rust drivers be slower or larger?
That is not where the risk sits. The Rust ASIX PHY driver is a single file under 150 lines, functionally equivalent to its C counterpart. The real costs are the toolchain, the unsafe blocks at every C boundary, any abstractions you have to write yourself, and the fact that you will own and maintain the driver without vendor support.

Should we rewrite our existing drivers in Rust?
No. The kernel is not asking for that, and neither is anyone else. Rust is for new code. A rewrite trades a driver that has been tested in the field for one that has not, in exchange for removing a class of bug the tested driver may not have been suffering from.

Further reading

• LWN — The state of the kernel Rust experiment, Jonathan Corbet’s report from the December 2025 Maintainers Summit session
• Rust for Linux — the project, its abstractions and its reference drivers
• drivers/net/phy/ax88796b_rust.rs — the reference PHY driver, in full
• Ferrocene — the qualified Rust toolchain for safety-related development
• TECH VEDA BSP Tracker — which kernel each vendor BSP pins, and when its fixes stop
• TECH VEDA — How U-Boot verified boot was broken by its own image parser

Kernel and driver work at this level — knowing which tree you are on, what it supports, and what it will cost to move — is what our Linux Device Drivers and Linux Kernel Infrastructure programs cover, on real hardware. And if the honest answer to question 1 of that checklist is that your kernel is the problem, that is the work our BSP and kernel maintenance team does with product teams every week.