The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

[ryao]

Classic example of Xorg quality, but morons praising microkernel brain dead design have no clue as usual. Tell me why there's no single use case for your broken by design piece of shit microkernel? Just don't come with 'layers between OS and hardware' examples. I want examples of real world usage and performance of this broken by design POS. Oh, and why even OpenBSD doesn't give a shit about your crap?

Cell phone baseband processors and the Intel ME use micro kernel designs. They are used in embedded systems where correctness is more important than performance.

[ryao]

I'm not a C dev, but doesn't

 && req->value == 1

mean that only a process named "X" would enter in this condition?

I'm not saying it's not a questionable solution, but if it's true then maybe it didn't affect as many processes as they thought.

No. That has nothing to do with the process name. Any process whose name starts with X will have this hack applied.

[ryao]

Xorg is fine they say. No need for Wayland they say...

It is fine. Modern systems use the mode setting driver, so issues in older DDX drivers that nobody use do not matter very much.

I suspect people blindly upvoting your ignorant comment have no clue about any of this.

[mercster]

Because god forbids I having a legit on topic doubt, right?

"Shoulda" stopped at user creation form junior user

It wasn't a doubt: you don't know how C works (let alone how kernel data structures work) and, for some reason, thought you'd question a kernel maintainer. And have no doubt, I've been using Linux since before you were born. I just don't run my mouth on forums when I don't know what I'm talking about. Stay in school!

[furtadopires]

Shoulda stopped there, bro. :-)

Because god forbids I having a legit on topic doubt, right?

"Shoulda" stopped at user creation form junior user

[ayumu]

To this hole microkernel thing most of the things where allready pointed out.

1. support from the hardware oem is needed for drivers, why code a new driver for something unknown if you have a working system with linux/windows
2. the modular approach, well linux has that vfs/block/mm/sheduler/driver, how long does it count as micro kernel, and when is it a full os, if you just have the kernel and no driver no filesystem no block layer no memory no pcie no gpu support that leaves you with just a BIOS and you can do nothing.
3. lets say you include drivers in the microkernel and each layer can reset from errors, you need to comunicate that an error accured to the kernel, that a module needs to be reset, and when a module is reset, it needs to reset all modules that have dependencies vfs->fs->block->nvme, in the case that an corruption took place in the vfs layer cache/buffer for block devices you need to restart 4 modules, and on top of that also reinitialize the pcie bus for the nvme drive, so the pcie registers are clear and in a sane state, to do that you need access to low level hardware registers and the knowledge for that driver wich again comes from OEM´s, you need a datasheet for that, and a NDA, oh my samsung nvme does this stuf on pci register xx and it should be reset to yy with a driver reset.

SO now you have the same problem linux has, you simply cant code a opensource os like that without the right stuff so whats the solution ?

Like linux and windows do you throw a bluescreen and simply reboot, cause the hardware blob knows how to do.

This microkernel aproach only works in highly special embedded systems with limited hardware and in an controled enviroment , like maybe miltary grade hardware, powerplants etc. where you know my chips from 1979 still work with it.

Your focus seems to be fault-tolerance. Look into Minix3, it has a lot of papers on the subject.

[ayumu]

The trouble with most microkernels is the IPC overhead. Pass a message, wait for the scheduler to switch cpu control to the other process, pass a message, wait for the scheduler, etc. Making most implementations significantly slower than a monolithic kernel.

AFAICT, the only succesfull microkernel OS that solved that particular problem is QNX, which tightly integrated message passing with cpu scheduling, thereby reducing unnecessary cpu cycles switching between processes. Pass a message, if the receiving process is waiting for it, give waiting process control over the cpu. Cuts out a lot of back and forth.

Have other microkernel OSes copied this behaviour? The patents should have expired by now, as QNX was initially released in 1982.

Look into Jochen Liedtke's research, and microkerneldude.org (in chronological order) as the natural continuation of that.

[mercster]

I'm not a C dev

Shoulda stopped there, bro. :-)

[sinepgib]

What a nice blend of 1) well-informed people who know the code and know the architecture and what they are talking about, and 2) random commentators looking to vent (unsolicited) regarding topics that are entirely tangential to the original Phoronix article.

Welcome to the Phoronix forums! Consistent quality since 2004.

Since we're all funny and sarcastic, let's also mention the passive aggressive observations that add nothing useful to either of the topics in play

[sinepgib]

Misbehaving code in a kernel simply crashes the kernel.

Again, ideally. I did write a bug in a custom Linux driver once that corrupted memory and it did not crash the system until much later than when the bug manifested. I was allocating one page less than I thought due to a lame attempt to be clever at math, so my driver ended up writing out of bounds corrupting the poor innocent soul that asked for the next page.
That wouldn't have happened in a microkernel because either that page was mapped by my process and it didn't (directly) affect other drivers or kernel tasks or it wasn't and the driver receives a segfault at the very moment of access, deterministically. What policy to follow when that happens would be probably defined on the basis of how critical the process is, of course. Crashing the OS gracefully or restarting.
Obviously, even in the first scenario there's no "no harm guarantee". For example, if the driver did corrupt itself now it would send unreliable results to processes asking it for data, so there could be a chain reaction. But that's still a reduction in the ways it can harm the user and specially their data.

A misbehaving usermode driver could keep being respawned over and over, corrupting more and more data.

If you choose to restart it, yes. But as you later noted, some critical services may be taken as a cue to graceful shutdown if they crash.

The whole point of critical OS code, whether userspace or kernelspace, is to kill the entire OS before anything else can happen.

Exactly. And which scenario makes this easier? Driver can corrupt the kernel page table or driver tries to write outside of its allowed addresses and simply crashes without affecting the rest of the system?

For some reason, people seem to think a microkernel has some sort of supernatural ability to keep an OS running when theres a critical bug in a driver or if the hardware is faulty.

On one hand, absolutely, some people seem to believe microkernels have stronger guarantees than they have. On the other hand, that's not at all what I suggest. It's just another mitigation that reduces blast radius. It's not a silver bullet.

No, it just means the kernelmode address space doesn't get clobbered.

Kernel mode and other drivers. It's not a minor thing that my GPU driver can't corrupt my VFS drivers IMO. One of them has much greater chances of borking my files than the other.