Strap in, get ready for more Rust drivers in Linux kernel
- Reference: 1741591210
- News link: https://www.theregister.co.uk/2025/03/10/rust_drivers_expected_to_become/
- Source link:
In a hopeful coda to [1]the recent maintainer drama that raised questions about the willingness of Linux maintainers to accommodate Rust code, Josh Aas, who oversees the Internet Security Research Group's Prossimo memory-safety project, late last week [2]hailed Miguel Ojeda's work to advance memory safety in the kernel without mentioning the programming language schism.
"While our goal was never to rewrite the entire kernel in Rust, we are glad to see growing acceptance of Rust's benefits in various subsystems," said Aas. "Today, multiple companies have full time engineers dedicated to working on Rust in the Linux kernel."
Our goal was never to rewrite the entire kernel in Rust ...
Since at least September last year, when Microsoft software engineer Wedson Almeida Filho left the Rust for Linux project citing "non-technical nonsense," it's been clear that acceptance had limits. Tensions between Rust and C kernel contributors flared again in January over concerns about the challenges of maintaining a mixed language codebase – [3]likened to cancer by one maintainer. Urged to intervene, Linux creator Linux Torvalds did so, making his annoyance known to [4]both [5]parties and prompting their departures as Linux maintainers.
Amid all that, Ojeda, who helms the Rust for Linux project, published a " [6]Rust kernel policy " as a way to clarify that those contributing Rust code to the Linux kernel should stay the course and to underscore that Linux leaders [7]still support the initiative.
[8]
According to Aas, the presence of Rust code is increasing in various Linux subsystems, including: PHY drivers, the null block driver, the DRM panic screen QR code generator, the Android binder driver, the Apple AGX GPU driver, the NVMe driver, and the Nova GPU driver.
[9]
[10]
"We expect that one of them will be merged into the mainline kernel in the next 12-18 months," said Aas, pointing to remarks from Linux lieutenant Greg Kroah-Hartman last November suggesting that the availability of Rust driver bindings represented a tipping point that would allow most driver subsystems to start getting Rust drivers.
[11]C++ creator calls for help to defend programming language from 'serious attacks'
[12]Open Source Initiative defends disallowing board candidate after timezone SNAFU
[13]How's that open source licensing coming along? That well, huh?
[14]Linux royalty backs adoption of Rust for kernel code, says its rise is inevitable
Once this happens, said Aas, "the goal of the effort will start to be realized: Products and services running Linux with Rust drivers will be more secure, and that means the people using them will be more secure, too."
Security – in the form of memory safety – is Rust's selling point.
Rust provides ways to avoid memory safety vulnerabilities that crop up in programming languages like C and C++ where manual memory management is allowed. Though other languages such as Python, Java, JavaScript, Swift, and C# are also considered memory safe, Rust has received most of the memory safety evangelism, partly because it's suited for the sort of low-level, performance-sensitive code that for the past few decades has tended to be written in C and C++.
[15]
As we [16]reported recently, the public adoration of Rust, and the public sector parroting of that message, has set off alarm bells in the C and C++ communities. Veteran C and C++ developers are not ready to call it quits, if that were even a plausible scenario.
Yet the future promoted by the Prossimo project, launched several years ago "to move the internet's security-sensitive software infrastructure to memory safe code" and "to change the way people think about memory safety," promises increasing marginalization and diminishing opportunities for C and C++ developers.
Earlier this week, Aas made it clear those prioritizing memory safety are keen to see C and C++ retired, even though there's widespread acknowledgement that C and C++ will be around for years and will need to be maintained.
[17]
"Many of the most critical software vulnerabilities are memory safety issues in C and C++ code, and while there are ways to reduce the risk, including fuzzing and static analysis, memory safety vulnerabilities continue to plague the Internet," said Aas in [18]a write-up .
"The good news is that with the rare exception of code that must be written in assembly for performance and/or security reasons (eg, cryptographic routines), we know how to get rid of memory safety vulnerabilities entirely: write code in languages that don't allow for those kinds of mistakes. It's a more or less solved research problem, and as such we don't need to suffer from this kind of thing any more. It can be relegated to the past like smallpox, we just have to do the work."
Between evocations of cancer and smallpox, it sounds like the Linux and Rust communities still have some issues to work out. ®
Get our [19]Tech Resources
[1] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[2] https://www.memorysafety.org/blog/linux-kernel-2025-update/
[3] https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
[4] https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/
[5] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[6] https://rust-for-linux.com/rust-kernel-policy
[7] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z87GVBeb0I4Tip_FruDjZAAAAAo&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z87GVBeb0I4Tip_FruDjZAAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z87GVBeb0I4Tip_FruDjZAAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2025/03/02/c_creator_calls_for_action/
[12] https://www.theregister.com/2025/02/28/osi_election_ai_drama/
[13] https://www.theregister.com/2025/02/24/open_source_licensing/
[14] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z87GVBeb0I4Tip_FruDjZAAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[16] https://www.theregister.com/2025/03/02/c_creator_calls_for_action/
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z87GVBeb0I4Tip_FruDjZAAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://www.memorysafety.org/blog/initiative-criteria/
[19] https://whitepapers.theregister.com/
Re: Such awful interop
This is why I love the el Reg forum. I don't really understand this post other than "somebody could have made things easier/better (allegedly)" but I've added it to my RSS feed and look forward to a pleasant day reading some informative back and forth knowing that there won't be a load of name calling and other poor BTL behaviour. And I might even learn something.
Re: Such awful interop
Like most reasons why Rust can't easily interop with C, it's because it would prevent the rust compiler from statically guaranteeing things. Just the #define keyword is already problematic because its untyped and that would put a hole in the Rust type-system.
There's many C-isms contained in header files that make it not possible to just be able to import them directly but tools like rust-bindgen exist to help.
look forward to a pleasant day reading some informative back and forth
One of the reasons I enjoy these forums is that I will often be prompted to go off and research something I didn't know much about, or to reflect on something I hadn't really thought about.
I'm not a Rust expert, but there is a tool, bindgen for Rust that automates the process of generating bindings for C code, though you may have to compile a list of the header files you want to feed to it. It seems reasonable to me that you'd use a separate tool for this purpose in Rust which has no notion of C syntax - whereas the C++ compiler already has most of what it needs.
Of course, if you're really worried about simplicity, you'd question the very existence of C header files - after all, it's not great to have to keep two separate files in sync with essentially the same information. But we seem to apply a different standard to things we're familiar with.
STL
C++ reached the same conclusion. But decided to get rid of the source file and leave only the headers...
Separating the interface from the implementation is not unique to C/C++, and is generally good practice. C++ will check the two files match.
> though you may have to compile a list of the header files you want to feed to it
Which is why we have makefiles.
It doesn't matter that you need one, two or ten utilities to massage a header from one format to another, so long as those transforms are reliable, accurate and can be managed by your build system (which is under source control, like everything else).
Personally, I like having interface structure definitions in yet.another.text.format and using *that* to generate the C include files as well as the files for whatever the C is talking to - and at the same time, C/whatever functions to print the structures in human readable form, pretty diagrams for the documentation (by spitting out inputs for Mermaid or other diagram drawing tools) etc.
That way, *everybody* is equally pissed off at writing "those stupid weird definition files, why can't I just use (native language format)?". To which the reply is "You can, but *you* are then responsible for keeping everything else up to date and the machines *will* email every time one of them needs to be updated (aint Make calls to blat wonderful?)".
Beware geeks bearing gifts
I can't code my out of a paper bag and I've no idea if Rust in the Linux kernel is a good or bad thing. But, and it's a big but, when Microsoft have a hand in 'doing something for Linux' I hear Klaxons and red lights start flashing. MS has form when confronted by competition. Even if the MS coder, or whomever, working on a project doesn't realise it, there maybe an underlying objective to cause problems for the project. Cynical? Moi?
Is Rust used in that paragon of reliability and security Windows?
Re: Beware geeks bearing gifts
Today's Microsoft isn't the same as the one from the Steve Balmer era.
I'm not trying to say it's all roses now with Redmond, but it's less hostile to the outside world.
> and is expected to translate into noticeable benefits shortly
Won't happen. Not in our lifetime.
Filling the Linux kernel with rotting bindings is not useful.
Such awful interop
I'd really like to know why Rust chose such an objectively stupid syntax for binding to C.
It's deliberately impossible to include a C header directly. So a single source of truth is impossible!
It must be "manually created", thus creating a source of memory errors and an artificial barrier to the adoption of Rust.
Apparently, you can use an automated tool to rearrange the syntax - if true, that proves it's different purely for the sake of being different and provides nothing. Why not specify that the toolchain does that, and allow compile-time checks to exist?
There is a reason C++ uses "extern C". It allows the use of the actual C header, and thus memory errors can be spotted by the compiler. A C++ "wrapper" is optional, and provides actual semantics like lifetime management.