Linux 6.16 Brings Faster File Systems, Improved Confidential Memory Support, and More Rust Support

ZDNet's Steven Vaughan-Nichols shares his list of "what's new and improved" in the latest Linux 6.16 kernel. An anonymous reader shares an excerpt from the report: First, the Rust language is continuing to become more well-integrated into the kernel. At the top of my list is that the kernel now boasts Rust bindings for the driver core and PCI device subsystem. This approach will make it easier to add new Rust-based hardware drivers to Linux. Additionally, new Rust abstractions have been integrated into the Direct Rendering Manager (DRM), particularly for ioctl handling, file/GEM memory management, and driver/device infrastructure for major GPU vendors, such as AMD, Nvidia, and Intel. These changes should reduce vulnerabilities and optimize graphics performance. This will make gamers and AI/ML developers happier.

Linux 6.16 also brings general improvements to Rust crate support. Crate is Rust's packaging format. This will make it easier to build, maintain, and integrate Rust kernel modules into the kernel. For those of you who still love C, don't worry. The vast majority of kernel code remains in C, and Rust is unlikely to replace C soon. In a decade, we may be telling another story. Beyond Rust, this latest release also comes with several major file system improvements. For starters, the XFS filesystem now supports large atomic writes. This capability means that large multi-block write operations are 'atomic,' meaning all blocks are updated or none. This enhances data integrity and prevents data write errors. This move is significant for companies that use XFS for databases and large-scale storage.

Perhaps the most popular Linux file system, Ext4, is also getting many improvements. These boosts include faster commit paths, large folio support, and atomic multi-fsblock writes for bigalloc filesystems. What these improvements mean, if you're not a file-system nerd, is that we should see speedups of up to 37% for sequential I/O workloads. If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux.

If security is a top priority for you, the 6.16 kernel now supports Intel Trusted Execution Technology (TXT) and Intel Trusted Domain Extensions (TDX). This addition, along with Linux's improved support for AMD Secure Encrypted Virtualization and Secure Memory Encryption (SEV-SNP), enables you to encrypt your software's memory in what's known as confidential computing. This feature improves cloud security by encrypting a user's virtual machine memory, meaning someone who cracks a cloud can't access your data. Linux 6.16 also delivers several chip-related upgrades. It introduces support for Intel's Advanced Performance Extensions (APX), doubling x86 general-purpose registers from 16 to 32 and boosting performance on next-gen CPUs like Lunar Lake and Granite Rapids Xeon. Additionally, the new CONFIG_X86_NATIVE_CPU option allows users to build processor-optimized kernels for greater efficiency.

Support for Nvidia's AI-focused Blackwell GPUs has also been improved, and updates to TCP/IP with DMABUF help offload networking tasks to GPUs and accelerators. While these changes may go unnoticed by everyday users, high-performance systems will see gains and OpenVPN users may finally experience speeds that challenge WireGuard.

Re:

[Anonymous Coward]

This argument is fundamentally flawed, both technically and philosophically. First, the claim that using the unstable version of Rust renders a project "untrustworthy" is misleading. The Linux kernel team is not recklessly adopting unstable Rust features selectively enabling well-audited nightly features in a tightly scoped, minimal way to bring memory safety into kernel-space without rewriting existing C code. Second, the idea that "everything is wrapped in unsafe anyway" in Rust shows a misunderstanding:

Re:

[haruchai]

" By the time Rust manages to stop changing underneath developers, both C and C++ will have venerable safety extensions that normal people can actually use"
The C programming language is over 50 years old and C++ is about 40 years old and both have been under constant development from day 1.
The fact that a programming language like Rust is even necessary should be an embarrassment to the C/C++ community.
At this point I doubt I have enough years left before the vaunted goal of "venerable safety extensions tha

Re:

[Uecker]

While I agree that C(C++ should have left no room for Rust by having perfect memory safety, the reality is that you can write very safe C/C++ code if you want to.
What Rust offers is the idea that you can achieve perfect memory safety without sacrificing performance. In practice, this is much less useful and bit based on exaggeration, but it makes for an excellent sales story. That other parts of the Rust ecosystem are a complete supply chain and maintenance disaster makes everything much less safe in reali

Re:

[DrXym]

the reality is that you can write very safe C/C++ code if you want to.

You could write safe C too if you want to. You could write safe assembly too if you want to. Unfortunately real world code is replete with errors caused directly by C++ language issues. And even if someone might strive to write safe C++ the compiler doesn't give a damn if it is or not. It might compile because it's safe. It might compile despite being unsafe. Forgot to lock that resource properly before accessing it from two threads? Storing a reference to something deleted elsewhere? LOL C++ doesn't care.

Re:

[vyvepe]

... the reality is that you can write very safe C/C++ code if you want to.

This is such a crappy argument! To illustrate I'll give you an analogy: You can walk very safely on stairs without handrails if you want to.
Despite that building codes generally require handrails for stairs.

Analogies

[Grady Martin]

I appreciate this analogy, but I also appreciate what I suspect was the original poster's intent.

To clarify: The handrail is already there. People just choose not to use it—some people out of ignorance or laziness, which is the real problem, other people when they are in a hurry or do not have a spare hand, which is perhaps understandable.

A more accurate analogy might be legislation that forces citizens to grip handrails, regardless of circumstance.

Re:

[dowhileor]

The obvious fact that no language on its surface is best for every situation Linux early on pushed C to its limits and I'm quoting its creator..... The solution was, given the requirements of the project new data types, soon-to-be-standard libraries, and gcc optimizations were developed along with the kernel.

Re:

[ZorroXXX]

the kernel would have been rewritten in C++ ages ago.

Fun fact, some kernel developer actually used g++ to compile the kernel with way back then [archive.org] (not to produce binaries, but because C++ had some stricter language features).

Re:But why Unstable Rust? Why so broken?

[DamnOregonian]

You are right, of course.

However, Rust's safety is still oversold.
The fact that dangerous operations are clearly demarcated does not change the fact that there are a lot of them, and they have CVEs.
Safe code can trigger bugs within unsafe code.
There was a concept in older languages of taint. Rust, as such- is tainted, even if it tries to pretend that it's not.
And that's ok.

As long as we admit it. Is it better than the fully-unsafe C? Yes, it is.
Is it likely to make a large difference? That's harder to say. The places where bugs happen in general are the same places where bugs have happened within Std::- areas that are severely optimized, and are marked unsafe specifically because bounds checks and other safety are too expensive or limiting.

I am an aging C veteran.
I'm not against Rust, though. I support it in the kernel fully. In no way is it a negative, it's a positive. But within that positive, exists the negative of its idiot cheerleaders.

Re:

[Uecker]

Lol, I guess I just made similar points replying to you in another thread. Ignore that.

Re:

[DamnOregonian]

Thumbs up.

Re:

[kertaamo]

I wonder where all those "idiot cheerleaders" of which you speak are? As a user of C since 1985 and C++ since 2000 or so that started with Rust five years ago I don't see them. I follow Rust forums, I listen to what Rust devs have to say. Never have I heard them making outlandish claims for Rust.

Where do you get that from?

Re:

[DamnOregonian]

That "idiot cheerleaders" == "Rust devs" is an inference you made on your own, and probably a bias you should spend some time evaluating to really understand.

But other than that, where do I get it from? Would you like a list of usernames?

Re:

[kertaamo]

You ignore the fact that the Linux kernel cannot be built with a standards compliant C compiler, it relies of GCC extensions. Where is the stability there? The accusation of lying about safety is absurd, they are very clear about what safety means in Rust. In my experiments Rust is not 6% slower, mostly it's neck and neck, sometimes Rust ahead a bit some times C ahead a bit.

When can we get more ZIG support?

[williamyf]

Alegedly, is faster than RUST and also memory safe.

We can let both duke it out in Linux KLM/Driver land. Outside enough of the kernel to not interfere, inside enough of the kernel to properly evaluate.

May the best meory safe language win.

Re:

[DamnOregonian]

Zig is not memory safe.
It includes some memory safety features, but so does C++. We don't call C++ memory safe for them.
I'm not sure it's worth it to add another language to the kernel if the benefits are dubious.
Not to mention Zig's allocator system would be the 9th fucking circle of hell in the kernel.

Re:

[Uecker]

Rust is also not memory safe. Safe Rust is memory safe. The main difference is that the safe subset of Rust is much clearer demarcated than in in C++, but the importance of this is massively oversold.

Re:

[DamnOregonian]

I don't recall saying anything about Rust, but yes, Safe Rust is memory safe. Unsafe Rust is not.

However, no Zig is memory safe. No C++ is memory safe.
It's true that they can be used in memory safe fashions, but that's up to the programmer. The language itself makes no guarantees.

Crate

[ArchieBunker]

Crate is Rusts packaging format? Why does a language have anything to do with packages?

Re:

[bjoast]

Why does a language have anything to do with packages?

While I do agree that cargo is bloat, I would like to point out that neither cargo nor crates are integrated parts of the Rust language and compiler. It is very much possible to build Rust programs without them. I've used only make and rustc for some projects.

Re:

[caseih]

Well we have to do something enable all those supply-chain attacks. Now we can have them in the kernel!

Re:

[DamnOregonian]

Basically. I'm pro-Rust-in-kernel, but very much anti-crates-in-kernel.

Re: Crate

[Phillip2]

I think you mean external dependencies. As far as I understand all the code needed to build Linux is in the tree. Only the rust standard library is "external". That the rust builds into several crates doesn't seem a worry to me.

Re:

[DamnOregonian]

I think you mean external dependencies

I do. Which are crates.

As far as I understand all the code needed to build Linux is in the tree.

It's true. The crates are pulled into the tree. That is not code that was written for the kernel, though. It does not, and cannot, go through the normal audit process.

Only the rust standard library is "external".

Rust in kernel is no_std. It does pull in core, and alloc, though. However- they are also not external. They're in-tree.

That the rust builds into several crates doesn't seem a worry to me.

The policy allows for the pulling of entire new crates into the tree. That should absolutely be a worry to you. This is how supply-side attacks happen.
People do not pull in libraries to the kernel in C

Re: Crate

[Phillip2]

In languages which do not have a defined packaging systems, many alternatives have appeared. Java and Python are good examples, where it has historically been a bit of a mess. C has no defined packaging system also. This can make it challenging to work out which libraries will actually be used when C is compiled or run, short of just running the compiler.

Cargo is a really nice feature of rust. Easy to develop against, easy to compile against.

Re: Crate

[OrangeTide]

I remeber when .shar was the package system for C.

Re:

[kertaamo]

It does not. Cargo and crates are one thing, the Rust compiler is another. You can build Rust with make files if you want to. You can write everything you need yourself if you want to. Just like C devs are rightly proud of doing. Rust does not stop you.

However thank God for cargo. So much nicer build system than anything in C/C++ world.

snapdragon

[blackomegax]

Also improved snapdragon 8cx gen 3 support. My thinkpad X13S works mostly right on this kernel. (ARM64 is still a 2nd class citizen though)

If security is a top priority for you

[Big Hairy Gorilla]

So, this implies that cloud providers can sniff your data out of RAM then ?

What about TXT? Who watches the watchers if it is proprietary?

Re: the fuck is this shit

[Phillip2]

Why would you get so angry about such a statement. In a decades time, we might see Rust starting to replace C. We might not. The story is just giving an idea of time scales. Decades not years. Or maybe never.

Re:

[kertaamo]

Stop listening to silly journalists or take them less seriously. Actual Rust devs do not advocate for rewriting huge projects of hundreds of thousands millions of lines. They are not stupid, they know that would be a ridiculously huge and expensive task with little benefit and a lot of downsides.

Re:

[DrXym]

And nobody has claimed any different. If code works and is stable then there is little justification to rewrite it. However if code is due for a rewrite or doesn't exist at all then why not write in a language that is not vulnerable to the problems that plague C.