Linux Kernel 6.10 Released (omgubuntu.co.uk) 15
"The latest version of the Linux kernel adds an array of improvements," writes the blog OMG Ubuntu, " including a new memory sealing system call, a speed boost for AES-XTS encryption on Intel and AMD CPUs, and expanding Rust language support within the kernel to RISC-V."
Plus, like in all kernel releases, there's a glut of groundwork to offer "initial support" for upcoming CPUs, GPUs, NPUs, Wi-Fi, and other hardware (that most of us don't use yet, but require Linux support to be in place for when devices that use them filter out)...
Linux 6.10 adds (after much gnashing) the mseal() system call to prevent changes being made to portions of the virtual address space. For now, this will mainly benefit Google Chrome, which plans to use it to harden its sandboxing. Work is underway by kernel contributors to allow other apps to benefit, though. A similarly initially-controversial change merged is a new memory-allocation profiling subsystem. This helps developers fine-tune memory usage and more readily identify memory leaks. An explainer from LWN summarizes it well.
Elsewhere, Linux 6.10 offers encrypted interactions with trusted platform modules (TPM) in order to "make the kernel's use of the TPM reasonably robust in the face of external snooping and packet alteration attacks". The documentation for this feature explains: "for every in-kernel operation we use null primary salted HMAC to protect the integrity [and] we use parameter encryption to protect key sealing and parameter decryption to protect key unsealing and random number generation." Sticking with security, the Linux kernel's Landlock security module can now apply policies to ioctl() calls (Input/Output Control), restricting potential misuse and improving overall system security.
On the networking side there's significant performance improvements to zero-copy send operations using io_uring, and the newly-added ability to "bundle" multiple buffers for send and receive operations also offers an uptick in performance...
A couple of months ago Canonical announced Ubuntu support for the RISC-V Milk-V Mars single-board computer. Linux 6.10 mainlines support for the Milk-V Mars, which will make that effort a lot more viable (especially with the Ubuntu 24.10 kernel likely to be v6.10 or newer). Others RISC-V improvements abound in Linux 6.10, including support for the Rust language, boot image compression in BZ2, LZ4, LZMA, LZO, and Zstandard (instead of only Gzip); and newer AMD GPUs thanks to kernel-mode FPU support in RISC-V.
Phoronix has their own rundown of Linux 6.10, plus a list of some of the highlights, which includes:
Linux 6.10 adds (after much gnashing) the mseal() system call to prevent changes being made to portions of the virtual address space. For now, this will mainly benefit Google Chrome, which plans to use it to harden its sandboxing. Work is underway by kernel contributors to allow other apps to benefit, though. A similarly initially-controversial change merged is a new memory-allocation profiling subsystem. This helps developers fine-tune memory usage and more readily identify memory leaks. An explainer from LWN summarizes it well.
Elsewhere, Linux 6.10 offers encrypted interactions with trusted platform modules (TPM) in order to "make the kernel's use of the TPM reasonably robust in the face of external snooping and packet alteration attacks". The documentation for this feature explains: "for every in-kernel operation we use null primary salted HMAC to protect the integrity [and] we use parameter encryption to protect key sealing and parameter decryption to protect key unsealing and random number generation." Sticking with security, the Linux kernel's Landlock security module can now apply policies to ioctl() calls (Input/Output Control), restricting potential misuse and improving overall system security.
On the networking side there's significant performance improvements to zero-copy send operations using io_uring, and the newly-added ability to "bundle" multiple buffers for send and receive operations also offers an uptick in performance...
A couple of months ago Canonical announced Ubuntu support for the RISC-V Milk-V Mars single-board computer. Linux 6.10 mainlines support for the Milk-V Mars, which will make that effort a lot more viable (especially with the Ubuntu 24.10 kernel likely to be v6.10 or newer). Others RISC-V improvements abound in Linux 6.10, including support for the Rust language, boot image compression in BZ2, LZ4, LZMA, LZO, and Zstandard (instead of only Gzip); and newer AMD GPUs thanks to kernel-mode FPU support in RISC-V.
Phoronix has their own rundown of Linux 6.10, plus a list of some of the highlights, which includes:
- The initial DRM Panic infrastructure
- The new Panthor DRM driver for newer Arm Mali graphics
- Better AMD ROCm/AMDKFD support for "small" Ryzen APUs and new additions for AMD Zen 5.
- AMD GPU display support on RISC-V hardware thanks to RISC-V kernel mode FPU
- More Intel Xe2 graphics preparations
- Better IO_uring zero-copy performance
- Faster AES-XTS disk/file encryption with modern Intel and AMD CPUs
- Continued online repair work for XFS
- Steam Deck IMU support
- TPM bus encryption and integrity protection
BSOD (Score:5, Informative)
NTSYNC (Score:1)
All I care about is NTSYNC, which alas is only stubbed in for 6.10. Fingers crossed for 6.11.
Always nice to see security updates... (Score:4, Insightful)
It is nice seeing a bunch of under the hood security improvements, from resistance to TPM bus snooping to faster AES-XTS. Since a lot of disks use LUKS, this is definitely going to be an I/O performance bump.
Overall, this is what is needed. I'm glad to see filesystem stuff getting improved upon. Btrfs has come a long way, initially from an ext3 replacement where ext4 was written as a bridge to btrfs to a filesystem that is used in many places (all new Synology NAS appliances use it by default, even the ARM models.) Now, if we can just see fscrypt() in btrfs so an encryption layer isn't needed on top (like eCryptFS), or below (like LUKS), that would be awesome.
Re:Always nice to see security updates... (Score:5, Insightful)
You mentioned Synology. As noted by Jim, Synology and Netgear NAS devices crucially layer Btrfs on top of traditional systems like LVM, in order to avoid its pitfalls. I am hoping that with Bcachefs, we won't have to do that.
Re: (Score:1)
What's the benefit of being in the Linux kernel, as opposed to being a module that gets loaded into the Linux kernel? Being able to boot without modules? Nobody cares about that any more. Being maintained with the kernel? That is no more or less likely than when it is distributed separately. Not having the kernel tainted? That's the only difference I can see. This is only a problem when trying to report kernel bugs, and it can also be caused just by implementing workarounds for machines with bad BIOS or oth
Re: (Score:2)
Incredibly good article!
As someone who has been using a stack of mdraid, LVM, and xfs or ext4, it was very very good to see some of the issues with that approach, but more so to see that Btrfs would be a step backward from my current approach. I've been casually considering Btrfs or OpenZFS for a long time; I think I'll stick with the thick stack (mdraid+LVM+xfs) for the foreseeable future.
Re: (Score:2)
I used to use a thick stack for my older NAS stuff, but have thrown in the towel and mainly use OpenZFS if there is enough RAM. However, if there isn't the ability to have the RAM overhead, I'd probably go with btrfs, even with its warts, just for the ability to deal with bit rot, maybe even repair it. I've been using it for a number of years, and have not had any major data losses due to the filesystem, as I have had with iterations of ReFS on Windows.
I have smacked into the recovery thing firsthand, whe
Re:Always nice to see security updates... (Score:4, Informative)
That article is 100% correct on a lot of fronts. One reason why Synology uses btrfs is that they have thrown some secret sauce into the kernel and the filesystem. If you check out the binaries on newer DSM revisions, Synology has added an entire "lock and roll" subsystem which does file locking, and expands on the chattr system of +i and +a, locking and unlocking as per time, which, assuming the clock isn't tampered with, and the device isn't compromised at the unconstrained root level, provides object locking.
Even with its issues, btrfs has its place. Not many filesystems have checksumming, and if one sets btrfs to use SHA256 on initial setup after using LUKS for the block volume, one now has authenticated encryption, which will be able to detect tampering. Putting btrfs on top of md-raid means that it can detect bit-rot, but can't fix it, but at least it is detected, and a scrub can find damage. Not many filesystems (definitely not XFS, which, at best, just checksums metadata) offer this.
btrfs also offers a few nice features as a filesystem. Compression and deduplication. Snapshots and the ability to send them off. The deduplication is nowhere near as good as ZFS which does it actively, and doesn't work with small files, but it does work with duperemove, and after the deduplication process finishes, doesn't require additional RAM. Downside is that it doesn't have (yet... work is being done on fscrypt) encryption, which means having to have a LUKS layer beneath it, or a layer like eCryptFS above it (which have their downsides, either having to use FUSE, character limitations, or eating up a ton of inodes like CryFS.)
As for Bcachefs, it has has a lot of promise. I have a feeling that eventually that is going to be what eclipses btrfs, especially because they have a solution for the write hole that is decently workable.
Overall, when in doubt, ZFS is the true king here. Even Ubuntu offers a way to boot from ZFS, and the way they handle ZFS boot level encryption is quite clever, using a small LUKS volume to store the ZFS key, so one can use multiple passwords with the LUKS keyslots, while having ZFS take it after the root filesystem's master key is loaded. Downside of ZFS is that it taints the kernel, and it is always a separate development effort, so one has to keep both in sync, which the devs with OpenZFS do well. It would be nice of Oracle could license ZFS under the GPL, just so it could be mainlined. This would pretty much solve the filesystem dilemma in Linux completely for almost everything but low RAM embedded environments, and for that, ext4 or bcachefs can be useful for those. However, if ZFS can't be used for stuff right now, then btrfs is "good enough" for most tasks.
Milk-V Mars in Mainline (Score:4, Informative)
Milk-V Mars in Mainline prepares the way forward for many variants of JH7110 CPU based boards to all use the same firmware and kernel builds, doing much of the fix-up at runtime for the differences. In fact, Pine64 and PCIe Host support missed this release cycle however they are queued for the merge window of what will become Linux Kernel 6.11
This is to say, it wasn't much to look at and I think raving about how wonderful the Milk-V Mars support is in Linux Kernel and Ubuntu mainline is absurd. It was a lot of work for the author to refactor the existing other devicetree sources for that same CPU and turned into yak shaving where you offer to fix one thing and are told "oh, that's great, we can do that when you fix nine other things your patch depends on but we are glad someone showed up to do all these things."
If you (the audience of /.) are at all curious about RISC-V, there are a range of boards running the JH7110 CPU which is cost effective, performant (somewhere between a mac m68k '040 and a Pentium II 450mHz), and if you have a serial UART adapter then recovery is easy and there's not a problem to brick the device from any firmware update. I recommend it preferably instead of some of the other RISC-V CPUs that claim to be 2x-30x the performance but have too many silicon errata to ever see upstream adoption. JH7110 boards from several vendors range from under $30 to well over $3000; I have a $30 board compatible to Raspberry Pi accessories and it's perfect for running any kind of compilation task, I do recommend anything with JH7110 CPU for your RISC-V experiments
Re: (Score:1)
performant (somewhere between a mac m68k '040 and a Pentium II 450mHz),
I've recycled machines I got for free which were faster than that.
That's not to say there's no use for those machines, but calling them "performant" is missing the mark by a lot.
Another useful link (Score:2)
FFS, code reviews are not gnashing... (Score:4, Insightful)
Real-time Linux? (Score:2)
Re: (Score:2)
You haven't seen updates because you haven't looked. Try this. [sched.com]