Linux 6.5 Kernel Released

ZDNet's Steven Vaughan-Nichols shares what's new in the release of Linux 6.5: The biggest news for servers -- and cloud Linux users -- is AMD Ryzen processors' P-State support. This support should mean better performance and power use across CPU cores. Intel Alder Lake CPUs have also received improved load balancing in a related development. RISC-V architecture fans will be pleased to find Linux now has Advanced Configuration and Power Interface (ACPI) support. ACPI is used in Linux and other operating systems for power management. It's vital for laptops and other battery-powered systems.

For better security, people using virtual machines or sandboxes based on Usermode Linux for testing, or running multiple versions of Linux at once, now have Landlock support. Landock is a Linux Security Module that enables applications to sandbox themselves by selecting access rights to directories. It's designed to be used by unprivileged processes while following the system security policy. To make talking with the rest of the world easier, Linux 6.5 now supports USB 4v2. This new USB-C standard will support up to an eye-watering 120Gbps. And while we're still getting used to Wi-Fi 6E, the Wi-Fi Alliance is already working on bringing us Wi-Fi 7. When Wi-Fi 7 arrives, with its theoretical maximum speed of 46Gbps, Linux will be ready. As usual, the new Linux has many more built-in audio and graphics drivers. The Bcachefs filesystem didn't make it into Linux 6.5, notes Vaughan-Nichols. "While the Bcachefs filesystem looks good, there's been a lot of developers fighting about the development process. These personal arguments have led Torvalds to decide not to incorporate Bcachefs into Linux 6.5."

Linus Torvalds announced Linux 6.5's delivery in a brief post on August 27.

Have they ported to microkernel yet?

[drnb]

Have they ported to microkernel yet? No. Meh.

Re:Have they ported to microkernel yet?

[caseih]

I think it's one of those ideas that has puristic and intellectual appeal to it. I remember learning about microkernels at uni.

But here we are all these years later and *no one* uses it in practice. No, Apple's XNU kernel is not microkernel. It can barely be called a hybrid. There is some of mach in there, but there is also a ton of practical, kernel-mode code in there to get the real work done.

I'm not sure we'll ever see a real microkernel -based OS, or ever need one.

Re:

[drnb]

Yeah, there is some academic interest. A world class professor named Tanenbaum would try to impress its benefits upon students.

https://en.wikipedia.org/wiki/... [wikipedia.org]

Re:

[chrism238]

Yeah, there is some academic interest. A world class professor named Tanenbaum would try to impress its benefits upon students.

And then along came Linus, and history has brought us to where we are today.

Re:Have they ported to microkernel yet?

[tlhIngan]

I think it's one of those ideas that has puristic and intellectual appeal to it. I remember learning about microkernels at uni.

But here we are all these years later and *no one* uses it in practice. No, Apple's XNU kernel is not microkernel. It can barely be called a hybrid. There is some of mach in there, but there is also a ton of practical, kernel-mode code in there to get the real work done.

I'm not sure we'll ever see a real microkernel -based OS, or ever need one.

Today there are no microkernel based OSes. But in the past, there were. And the biggest ones came from our friends in Redmond.

NT was a microkernel at first until 4.0 when they rolled graphics into the kernel. These days, not so much as most of the other services were rolled into modern Windows 10/11.

Windows CE was a true microkernel OS as well, with everything based on servers - you had the Windows CE kernel as nk.exe which had your HAL, device drivers were hosted inside a user space executable device.exe, and so on.

Of course, CE is pretty much dead - Microsoft still sells it as Windows Embedded Compact - https://learn.microsoft.com/en... [microsoft.com]

But it's effectively dead - I mean, Compact 7 was following Windows 7, and Compact 2013 is the last release following Windows 8 (purely by looks - the two OSes have diverged quite significantly).

The only remaining microkernel OS used widely today would be QNX, basically automotive services.

Re:

[drnb]

The only remaining microkernel OS used widely today would be QNX, basically automotive services.

Well technically any microcontroller environment that wants a POSIX API.

Re:

[drinkypoo]

NT was never a microkernel-based system, because the processes never ran on the microkernel. They always ran on the kernel. The change from NT3.51 to NT4.0 wasn't what you think it was. They just stopped separating graphics off into its own protected memory from the rest of the kernel. OSX is more microkernel-based than NT ever was, because the processes run on the microkernel.

Re:

[ichthus]

The only remaining microkernel OS used widely today would be QNX, basically automotive services.

I do firmware for a biomedical company, and we make a device that runs on QNX. It is a microkernel, but we don't really care about that -- we use it, because it's real-time, and POSIX compliant.

Re:

[ichthus]

...and I HATE the QNX 6 filesystem. For our next generation, I'm going to advocate switching to embedded Linux. For areas where we need RT control, we'll run Free RTOS or some such on a separate core.

Re:

[The Evil Atheist]

IPC to communicate across different address spaces will always be more expensive than not doing it.

So whatever hardware developments can possibly make microkernels fast enough, monokernels will run faster on it still. On real world workloads, monokernels on the new hardware will always appear faster and feel snappier than microkernels, and that annoyance will be enough to dissuade most people in most environments from microkernels.

Only when things are so slow that it doesn't matter to end users will m

Re:

[drnb]

Only when things are so slow that it doesn't matter to end users will microkernels gets used.

Also when the hardware is so much faster than what the application requires. Then the overhead is meaningless as it does not translate into perceivable performance degredation.

Possibly also in environments that require incredible reliability and robustness. See embedded environments using QNX.

Re:

[KiloByte]

IPC to communicate across different address spaces will always be more expensive than not doing it.

No. That's true only with current approaches, on current hardware.

Hardware solution: maintain separate state for various OS components, requiring minimal or no overhead (see eg. register aliasing) to switch. Heck, if these are not both regular-purpose cores, you can get the IPC to be faster. See eg "DSA" (a glorified blitter) present in some new Intel gear, it's a specialized core that can do only stuff like memory copies, clears, comparison, hashing, etc -- but it works in parallel with other cores, tak

Re:

[The Evil Atheist]

You curiously ignored the rest of my argument (which I stole from Linus Torvalds):

So whatever hardware developments can possibly make microkernels fast enough, monokernels will run faster on it still.

Whatever fancy new hardware that makes IPCs faster, such as dedicated memory circuitry, will be used to make monokernels run EVEN faster than before, which means microkernels will never catch up in terms of raw speed.

So outside of microcontroller environments, people will continue to compare the snappiness of monokernels to microkernels and go with the less annoying option - the one that lags less, due to the lack of cross

Re:

[The Evil Atheist]

You curiously ignored the rest of my argument (which I stole from Linus Torvalds):

In fact, no. Even the sentence you quoted already defeats your argument.

IPC to communicate across different address spaces will always be more expensive than not doing it.

Whatever specialized hardware you can come up with, even if it had planck-time speed, is not going to be more expensive than not doing it. Not doing something is ALWAYS zero. You cannot beat zero with more hardware.

Which makes this irrelevant:

A specialized piece of hardware can have less latency than a memory access or an atomic barrier.

The memory you shift around will eventually needed to be accessed, and probably be needing some kind of synchronization. For one, you'd still need to lock the memory range while you do a copy, be

Re:

[The Evil Atheist]

is not going to be more expensive than not doing it.

Of course, I meant less.

Re:

[KiloByte]

Communication with that special chip, if done via a channel that doesn't touch memory, might either not require synchronization, or provide it implicitly. And on a modern CPU, any kind of outside synchronization is costly -- and if we're talking about a multi-socket machine, it's a "pack up, go on a fishing trip, and check once a day if synchronization is done" affair.

Just for some numbers: a nasty long lock-free function I wrote executes an iteration in below a nanosecond, the same thing as a trivial, cle

QNX. IntelME.

[DrYak]

I'm not sure we'll ever see a real microkernel -based OS, or ever need one.

QNX, looking at you from the hood of your car (with it's thousand tiny embed eyes) (*):
"Am I nothing to you?..."

Meanwhile:
Ring -3” Intel Management Engine (ME): "Yeah, sure, nothing to see here. Move along. This isn't the Minix you are looking for..." (waves hand in Jedi mind trick way).

---

(*): and, depending on the brand of car, also from the big infotainment screen if it's not running the usual and almost omnipresent Linux + QtEmbed (or Android).

Re:

[vbdasc]

I'm not sure we'll ever see a real microkernel -based OS, or ever need one.

Debian GNU/Hurd?

Re:

[posixively_true]

Richard Stallman, is that you?

Re:

[vbdasc]

His Slashdot user id has less than 6 digits.

fscrypt in btrfs please...

[ctilsie242]

Wish they could have mainlined fscrypt in btrfs. What this would offer is a nice COW filesystem with built in encryption, which would be quite useful for SSD based devices.

Re:

[drinkypoo]

What this would offer is a nice COW filesystem with built in encryption, which would be quite useful for SSD based devices.

psst ZFS.

Re:fscrypt in btrfs please...

[ctilsie242]

ZFS is definitely the best of breed. However, it requires a lot of RAM for it to be useful, and there is the licensing. If Larry allowed ZFS to be mainlined into the Linux kernel like what MS did with ExFAT, different story.

For something like a phone or low RAM device, and where the FS is supported in the kernel, btrfs is still useful, and having fscrypt only will help things.

Re: fscrypt in btrfs please...

[drinkypoo]

What effect does the licensing have on your ability to use zfs?

Still no NFSv4 ACLs....

[codebase7]

One of the biggest problems with Linux filesystem security is the dated (RWX) permissions system. Pretty much anything else that tries to "secure the Linux filesystem" is effectively adding a subset of NFSv4 ACLs, but without actually adding NFSv4 ACLs. (The immutable bit, suid, SELinux labels, etc.) Add to that the ACL support that Linux does have is rendered completely worthless the second anyone runs chmod and you get more things like Landlock.

Of course the often trotted out reason they don't add NFSv4 ACLs is "backwards compatibility." Which I love to call BS on. They add support for things like Landlock and various other LSMs all the time. Worse, a good number of these LSMs break userspace all the time. To the point that the addage when anything goes wrong is to "drop the shields" A.K.A. Disable all LSMs. There's no reason they couldn't add NFSv4 ACL support as an LSM and gate it behind a kernel command line option that's disabled by default. (Or mandate it be built as a loadable kernel module only.) Hell, they could even add a flag as well that controls what happens when support is enabled and some old program tries to run chmod. Instead all we get are the handful of old out-of-tree kernel patches that have been around forever, and a bunch of random other "security" APIs that desperately try to implement workarounds for the RWX crap's deficiencies.

Can we all just agree that sometimes you need more than just RWX? Not everyone should be able to overwrite / delete a file just because they have W but they do need to be able to append / create a new file with a different name. Not everyone needs all of the permissions that the "mask" allows. Some of that might be harmful but for organizational reasons you can't just move them into another group. (Also compounded by the lack of nested group support so anything beyond a handful of users / groups gets real messy real quick, but I digress....) Some may want to protect the ACLs from inspection by unprivileged users to prevent information leaks to attackers. (What users / groups they should target to acquire access, who to spoof changes with, or who to target with a phishing campaign.) And of course, there's the interoperability case as well. (Samba and Wine would love getting something like NFSv4 ACLs natively supported.) There's plenty of real world reasons for more fine grained permissions than RWX provides. Some of which are the reasoning behind the creation of these other LSMs. We should be able to implement something better.

Re:

[KiloByte]

Well, seeing the inmitigated success that rich ACLs have brought to Windows, I'd say: no thanks.