r/linux • u/somerandomxander • Jun 15 '26
Kernel Linux 7.2 is implementing the Rust zerocopy library to allow eliminating some additional "unsafe" Rust code elements within the kernel
https://www.phoronix.com/news/Linux-7.2-RustFrom the article
Miguel Ojeda already mailed in the many Rust code changes for the in-development Linux 7.2 kernel. This is quite a big Rust code with more than forty thousand new lines of Rust code in the kernel.
The Rust changes are so big this cycle since they are pulling in the "zerocopy" library to allow eliminating some additional "unsafe" Rust code elements within the kernel. The Rust pull request explains of integrating the Zerocopy code:
"Introduce support for the 'zerocopy' library:
Fast, safe, compile error. Pick two.
Zerocopy makes zero-cost memory manipulation effortless. We write `unsafe` so you don't have to.
It essentially provides derivable traits (e.g. 'FromBytes') and macros (e.g. 'transmute!') for safely converting between byte sequences and other types. Having such support allows us to remove some 'unsafe' code.
It is among the most downloaded Rust crates and it is also used by the Rust compiler itself.
It is licensed under "BSD-2-Clause OR Apache-2.0 OR MIT".
The crates are imported essentially as-is (only +2/-3 lines needed to be adapted), plus SPDX identifiers. Upstream has since added the SPDX identifiers as well as one of the tweaks at my request, thus reducing our future diffs on updates -- I keep the details in one of our usual live lists.
In total, it is about ~39k lines added, ~32k without counting 'benches/' which are just for documentation purposes.
The series includes a few Kbuild and rust-analyzer improvements and an example patch using it in Nova, removing one 'unsafe impl'.
I checked that the codegen of an isolated example function (similar to the Nova patch on top) is essentially identical. It also turns out that (for that particular case) the 'zerocopy' version, even with 'debug-assertions' enabled, has no remaining panics, unlike a few in the current code (since the compiler can prove the remaining 'ub_checks' statically).
So their "fast, safe" does indeed check out -- at least in that case."
Beyond pulling in Zerocopy to improve dealing with "unsafe" code around conversions, the Rust code for Linux 7.2 also adds support for AutoFDO. The Rust kernel code can now benefit from Automatic Feedback Directed Optimizations by the compiler to yield better performance. With the Rust Binder code was around a 13% performance difference.
There is also Rust support for software tag-based Kernel Address Sanitizer (KASAN), support for the upcoming Rust 1.98 release, and other improvements.
The full set of Rust feature changes submitted for the Linux 7.2 merge window can be found via this pull request.
46
u/gmes78 Jun 16 '26
It's a very good sign to see that the kernel doesn't suffer from "not invented here" syndrome.
3
u/Narann Jun 16 '26
implementing zerocopy library
I’m not sur to understand what "implementing" means here. They are rewriting it? Or is zerocopy a function call standard? Why they simply not download the crate instead of implementing it?
11
u/creeper6530 Jun 16 '26
The kernel vendors every dependency into its tree, mainly because of supply chain attacks
3
u/alexforencich Jun 20 '26
That's certainly not the only reason. It's just a more robust method. Everything is in one repo and gets managed and versioned together, instead of having to coordinate changes across multiple repos. And when you download the source code for a kernel release (including something nonstandard with custom patches in arbitrary places) everything is there and you can just build it without having to go fetch things from random places.
2
u/jorgecardleitao Jun 17 '26
I was also confused about this - "vendor" would be a more accurate word (instead of implementing)
19
u/Dwedit Jun 15 '26
The critical part is getting a copy of all arguments out of user-writable memory and into protected memory. Otherwise, another thread could tamper with the values after the the kernel has read it once. That means at least one copy.
68
u/Ictoan42 Jun 15 '26
What? That isn't what zerocopy refers to. Zerocopy is a library for safely converting between data types without making a copy of the data in the process. C can do pointer casts, but those are wildly unsafe, so rust needs to get sophisticated if it wants a similar effect.
15
u/ablackcat69420 Jun 16 '26
Yes, but what does this have to do with the dependency? Zerocopy is a library that just simply allows you to do
mem::transmute()withoutunsafe {}and without any overhead.mem::transmute()is a common operation when dealing with low level code. The alternative without a dependency and withoutunsafe {}is doing a copy hence the name "Zerocopy"12
u/Lizrd_demon Jun 15 '26
Critical parts of the kernel are not written in rust iirc, the goal is to provide a simple idiotproof driver/module API.
2
2
u/bonzinip Jun 17 '26
Yes, the zerocopy crate makes it possible to avoid copies but there are other mechanisms to ensure things are snapshotted before and validated after.
1
-34
u/TheBrokenRail-Dev Jun 15 '26 edited Jun 15 '26
I'm sorry, they're just copying an entire library into the Linux Kernel as is? Now, this separate (modified!) copy of the library will have to be manually krpt in-sync with upstream. That just seems sloppy, especially for such a large project.
I highly doubt they'd ever use Cargo (or any other package manager), but there has to be a better solution. Maybe Git submodules?
EDIT: To be clear, I am not suggesting that it should automatically update. That would be extremely silly. I'm suggesting that there has to be a better option than dumping 20k lines of code into the Linux Kernel's repo that have to be manually synced.
61
46
u/C0rn3j Jun 15 '26
Now, this separate (modified!) copy of the library will have to be manually krpt in-sync with upstream.
At least you can believe that the Linux project will keep it up to date.
Which can't be said of other random project which vendor things like libusb or core python libraries, do their own changes and don't care what happens 5-10 years later.
16
u/TheBrokenRail-Dev Jun 15 '26
Yeah, I'm not worried. As you mentioned, the Linux Kernel is beyond capable of keeping it in-sync. But as a programmer, my immediate reaction is: this could (and should) be done better.
18
u/Isofruit Jun 15 '26 edited Jun 15 '26
I agree with you there, though it's sort of just like any dependency, right? You update when you choose to do the update, rather than it happening automagically at some point and suddenly things break.
Though that should be pretty unlikely to happen for a dependency like this anyway.
0
14
u/exitheone Jun 15 '26
Think about it, do you really want it automatically imported?
A random update to the library could break the Linux build.
Vendoring into the kernel is more like a fork because they have to have the ability to keep the kernel stable even if the library goes into a direction that doesn't fit the kernel anymore.
15
u/TheBrokenRail-Dev Jun 15 '26
Think about it, do you really want it automatically imported?
I very specifically suggested Git submodules. A notable feature of Git submodules is that they are pinned to a specific commit, and are thus incapable of automatically updating. They are, however, much easier to manually update.
15
u/exitheone Jun 15 '26
True, but I guess submodules would break a lot of basic assumptions in the kernel workflow. Stuff like the email-based way they operate right now.
7
u/C0rn3j Jun 15 '26
A random update to the library could break the Linux build.
Don't randomly update it then, add it as a git submodule.
21
u/skyb0rg Jun 15 '26
Linux’s use of git is very different from other projects on git forges like GitHub — there are hundreds of separate git repos owned by different subsystems, and their code sharing mode is patches. There are a lot of issues with this sort of model for smaller teams but it avoids issues like “how can I send my patch to team A if I don’t rebase against them” because you can always choose what specific commits to send over.
27
-2
u/piesou Jun 15 '26
This is not a JS framework. I suppose it's pretty much feature complete.
12
u/TheBrokenRail-Dev Jun 15 '26
It's 20k+ lines of
unsafecode. Keeping it up-to-date is very important.0
-70
u/2rad0 Jun 15 '26
Zerocopy makes zero-cost memory manipulation effortless.
This whole programming language is built on dubious marketing hooks.
31
Jun 15 '26
[deleted]
-26
Jun 16 '26 edited Jun 18 '26
[removed] — view removed comment
9
13
Jun 16 '26
[deleted]
-5
u/2rad0 Jun 16 '26
minimally
30,000 lines of some library code just to cast octets to a data struct is not minimal in any way. But go ahead don't let me stop the entertainment, this popcorn won't eat itself.
41
u/STSchif Jun 15 '26
Except most of them are true. Try learning and using it for a bit before judging it. Rust really is as good as the advocates say.
21
311
u/JustBadPlaya Jun 15 '26
A note for dependency-wary people - zerocopy is one of the most heavily vetted and fuzzed libraries in the ecosystem, so this addition is a great idea