I feel obligated to give some context about why they are excited, since the article seems to be targeting people who understand. Specifically, this part:
"blue screen of the death" or "Oops"... except that it's just an error! It doesn't take your whole system away with it, only the particular operations that was going on.
There are two theoretical kernel architectures: Microkernel, and monolithic kernel.
The primary advantage of a monolithic kernel is performance. All modern operating systems a monolithic kernels [1]. The big advantage of a microkernel is security.
With a monolithic kernel, almost everything runs privileged, in the kernel. Hardware interactions, drivers, firewalls, various processes. The big disadvantage of this, is that if any of those components have a bug and crash, it bluescreens.
The best example was the crowdstrike blue screen of death issues: https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages . Crowdstrike runs at the kernel level (kind of like kernel level anticheat), and it had a bug, causing BSOD's everywhere. Of course, this is a fairly drastic example. Anecdotally, I have noticed in an increase in random BSOD's from people who have kernel level anticheat installed. Of course, the average user never whines and you have to pull this out of them, they just treat this as "normal".
With a microkernel, things are different. Everything is separated out, running as less privileged processes. This has big security implications since, it means that pwning one component of the Linux kernel, wouldn't own the whole kernel. That has been how so many of the recent Linux kernel root exploits have happened, where subsystems, rather than the entire kernel are vulnerable. With a microkernel, the possibility of an exploit in say, the containerization/sandboxing features, wouldn't lead to a root exploit on the host. SImilarly, components like device or filesystem drivers could be put in userspace as well, enabling much better security and isolation.
[1], well, sometimes people try to argue that the difference between a microkernel and a monolithic kernel is about codebase organization, optimizing for development velocity. Windows, and Mac are called "hybrid kernels", because the core kernel code is separated from things like drivers, enabling people to develop them separately. This used to be a bigger deal back in the day, since it enabled faster development for things like peripherals.
But there is no security or correctness benefit, so I consider them a monolithic kernel. In addition to that, "true" monolithic kernels (like Linux) have since innovated. While being open source may not be a big deal to us today, it was an innovation on it's own, that enabled people to include the firmware/drivers in the kernel directly (albeit, sometimes as binary blobs distributed in linux-firmware). In addition to that, there is also dkms for loading out of tree kernel modules, or epbf which enables you to run arbitrary code with ring 0 level privileges... but in such a way that it also doesn't hard crash the system when there is a bug.
3 Comments
blamster19@programming.dev · 3 pts · 17d
Is GNU Hurd stable enough to actually use it? Has anyone tried it and can say something about it?
tabular@lemmy.world · 3 pts · 17d
I think it doesn't support USB yet.
I can't talk to if it's stable. It seems the question before that is does it support my needs/devices.
moonpiedumplings@programming.dev · 2 pts · 16d
I feel obligated to give some context about why they are excited, since the article seems to be targeting people who understand. Specifically, this part:
There are two theoretical kernel architectures: Microkernel, and monolithic kernel.
The primary advantage of a monolithic kernel is performance. All modern operating systems a monolithic kernels [1]. The big advantage of a microkernel is security.
With a monolithic kernel, almost everything runs privileged, in the kernel. Hardware interactions, drivers, firewalls, various processes. The big disadvantage of this, is that if any of those components have a bug and crash, it bluescreens.
The best example was the crowdstrike blue screen of death issues: https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages . Crowdstrike runs at the kernel level (kind of like kernel level anticheat), and it had a bug, causing BSOD's everywhere. Of course, this is a fairly drastic example. Anecdotally, I have noticed in an increase in random BSOD's from people who have kernel level anticheat installed. Of course, the average user never whines and you have to pull this out of them, they just treat this as "normal".
With a microkernel, things are different. Everything is separated out, running as less privileged processes. This has big security implications since, it means that pwning one component of the Linux kernel, wouldn't own the whole kernel. That has been how so many of the recent Linux kernel root exploits have happened, where subsystems, rather than the entire kernel are vulnerable. With a microkernel, the possibility of an exploit in say, the containerization/sandboxing features, wouldn't lead to a root exploit on the host. SImilarly, components like device or filesystem drivers could be put in userspace as well, enabling much better security and isolation.
[1], well, sometimes people try to argue that the difference between a microkernel and a monolithic kernel is about codebase organization, optimizing for development velocity. Windows, and Mac are called "hybrid kernels", because the core kernel code is separated from things like drivers, enabling people to develop them separately. This used to be a bigger deal back in the day, since it enabled faster development for things like peripherals.
But there is no security or correctness benefit, so I consider them a monolithic kernel. In addition to that, "true" monolithic kernels (like Linux) have since innovated. While being open source may not be a big deal to us today, it was an innovation on it's own, that enabled people to include the firmware/drivers in the kernel directly (albeit, sometimes as binary blobs distributed in linux-firmware). In addition to that, there is also dkms for loading out of tree kernel modules, or epbf which enables you to run arbitrary code with ring 0 level privileges... but in such a way that it also doesn't hard crash the system when there is a bug.