Linux 6.16 Brings Faster File Systems, Improved Confidential Memory Support, and More Rust Support (zdnet.com)
- Reference: 0178507050
- News link: https://linux.slashdot.org/story/25/07/29/2118206/linux-616-brings-faster-file-systems-improved-confidential-memory-support-and-more-rust-support
- Source link: https://www.zdnet.com/article/linux-6-16-brings-faster-file-systems-improved-confidential-memory-support-and-more-rust-support/
> 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 [2]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.
[1] https://www.zdnet.com/article/linux-6-16-brings-faster-file-systems-improved-confidential-memory-support-and-more-rust-support/
[2] https://lore.kernel.org/lkml/CAHk-=wh0kuQE+tWMEPJqCR48F4Tip2EeYQU-mi+2Fx_Oa1Ehbw@mail.gmail.com/T/#u
When can we get more ZIG support? (Score:2)
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: (Score:2)
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: (Score:2)
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.
Crate (Score:2)
Crate is Rusts packaging format? Why does a language have anything to do with packages?
Re: (Score:2)
> 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: (Score:2)
Well we have to do something enable all those supply-chain attacks. Now we can have them in the kernel!
Re: (Score:2)
Basically. I'm pro-Rust-in-kernel, but very much anti-crates-in-kernel.
Re: Crate (Score:3)
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 (Score:2)
I remeber when .shar was the package system for C.
Re: (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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: (Score:2)
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: (Score:1)
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: (Score:3)
" 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: (Score:2)
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:But why Unstable Rust? Why so broken? (Score:4, Interesting)
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: (Score:2)
Lol, I guess I just made similar points replying to you in another thread. Ignore that.
Re: (Score:2)
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: (Score:2)
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.