Monolithic or microkernels?

[Marco]

Yes, bugs do always exist; so, we layer security

Meltdown burned through all of it. The difference between what's a layer and what's a link is hard to predict.

Any way, kernels are monolithic despite decades of exploits ... not much layering going on inside them. Software only approaches have the advantage of not needing to upset the TLB with all the involved delays and they can run on processors without any MMU at all.

[DiTBho]

With a programming which guarantee isolation at the language level you could have isolated kernel components entirely without hardware support.

It is not proper isolation, proper security: it is purely a theoretical option that does not provide any isolation guarantees in practice.

I do strongly believe that "isolation" can only achieved by "hardware segregation".

[DiTBho]

You essentially propose to replace the entire graph or stack of guarantees with the single one provided by a programming language implementation. 

indeed the ICE_AI driven of my-c doesn't trust any stack of guarantees in any of the monads used in my-c, and, instead, checks everything at run-time; and even this way, there are some undetected and uncatched bugs and vulnerabilities still lurking around, hidden somewhere, waiting to bite you, and they will when you less expect it.

[Nominal Animal]

Yes, bugs do always exist; so, we layer security

Meltdown burned through all of it.

I disagree.  I consider only remotely exploitable privilege escalations as such.

Meltdown meant virtual memory protections are circumventable on certain processor architectures, unless relatively costly software workarounds are applied.  As such, it was a very serious local privilege escalation risk.  As a silicon design bug on more than one design, it was unusual and widespread, affecting all operating systems running on such hardware.  But it did not "burn through all security".

The difference between what's a layer and what's a link is hard to predict.

I don't follow.  What do you mean by 'link'?  By 'layer', I refer to each security promise or guarantee, as they are structured and rely on each other to provide the overall security in a system.

The first 'layer' is input filtering and buffer overrun protection in userspace applications.
The second 'layer' is process isolation and kernel-userspace barrier via virtual memory.
The third 'layer' is the kernel verifying parameters and scrubbing kernel-internal information in unused registers and userspace-visible structures when returning to userspace.

Each of these can be split into security sub-promises, of course.  While these are traditionally described as a stack, a graph would be more correct.

In Unix/POSIX systems, for example, it has always been typical that application binaries are not writable by normal users (without privilege escalation).  This means that even if you manage to inject code into a running user process, it is nontrivial for that process to infect other binaries.  This, too, is a security 'layer', only a purely userspace design one.
 _ _ _

There is no difference to the userspace security under monolithic and microkernels: all currently known designs can be implemented under both equally well.  The main security difference is that microkernels have internal privilege separation, similar to userspace processes, within the kernel itself; whereas monolithic kernels are more similar to a single userspace process.

Replacing all of that with the security promises a programming language provides is a ridiculous trade.

[Nominal Animal]

With a programming which guarantee isolation at the language level you could have isolated kernel components entirely without hardware support.

It is not proper isolation, proper security: it is purely a theoretical option that does not provide any isolation guarantees in practice.

I do strongly believe that "isolation" can only achieved by "hardware segregation".

I agree, because I have never heard of any way of providing similar strength/reliability of security promises, in software.

Yet, hardware segregation alone does not provide full system security; no single feature does.  It is a good start, though.
To do useful work, our kernels and userspace software needs the ability to bypass hardware segregation in specific cases: the kernel-userspace barrier and interprocess communication being the most commonly used ones.

You could say that security-wise, microkernels extend the security 'layering' (in the sense I defined in my previous answer above) into the kernel itself, making sure each part or subsystem of the kernel has only access to what it actually needs.  In monolithic kernels, all kernel code has equal access to all hardware and all userspace processes; there are no kernel-internal "security barriers".

Interestingly, many of the microcontrollers I use have rudimentary hardware segregation/protection, at least in the form of registers that can only be modified when a separate "lock" register contains a specific value.  (The more advanced ones also have memory access protections, even when they have no virtual memory support.)  Many support splitting the built-in Flash memory to a write-protected bootloader area, even when the rest of the Flash is updated.
In this sense, it is difficult to separate 'security' from 'robustness', because both are essentially about trying to fulfill the promise of "correct operation".

Since current general-purpose computer hardware can provide the hardware segregation with neglible overhead, it is obvious that a microkernel design can be more secure/robust than a monolithic one, simply because most of the necessary aforementioned holes in e.g. the kernel-userspace barriers don't open up the entire hardware, but only a small part.

[Marco]

I don't follow.  What do you mean by 'link'?  By 'layer'

An allusion to chain being as strong as its weakest link.

Meltdown burned straight through all read protection layers. The hardware protection was a link, not a layer.

[DiTBho]

@Nominal Animal
(quoting your points in a list)

• layer1: input filtering and buffer overrun protection in userspace applications
• layer2: process isolation and kernel-userspace barrier via virtual memory
• layer3: kernel verifying parameters and scrubbing kernel-internal information in unused registers and userspace-visible structures when returning to userspace

Specifically, my automatic tools check layer1 and layer3. Layer2 is not currently checked.

Plus, I have a seriously problems checking physical addresses to virtual addresses without triggering unwanted hardware reaction. So, at the moment, I am using a kind of "kgdb-like" (linux kernel gdb) software tool instead of the ICE-tap.

With MIPS, both cache and TLB are not friendly when you have to use invasive hardware tools to inspect them.

[SiliconWizard]

Just stumbled upon this video:

(This is not a promotion of this guy's channel, which I didn't know before.)

He goes through the famous discussion between Linus and Andrew. One can see that heated online technical discussions were already a thing 30 years ago.
I find it interesting to go through all the arguments in retrospect, the assertions that were made, and where we are now.

[Marco]

I agree, because I have never heard of any way of providing similar strength/reliability of security promises, in software.

Javascript containment in the major browsers is more on the level of VM containment than local process containment, they also use process isolation but that's ultimately the lesser of their security guarantees.

There's always software border guards, which are usually the weak point outside of corner cases like Meltdown. Escapes through privilege escalation using faulty APIs, VM escapes use faulty virtualization services running on the host, etc. With the right architecture, a pure software solution doesn't need many more LoC attack surface than process/VM isolation.

[ejeffrey]

Three major points that I see in favor of the "microkernel" approach - which I would actually like to see in software in general, not just kernels - are: 1/ isolation, 2/ modular designs with small, manageable chunks and 3/ message passing and much saner handling of resource sharing.

Now of course, what may have been problematic 30 years ago on 386 computers has become irrelevant to a significant extent.

Maybe.  But while computers have gotten dramatically faster, the relative cost of context switching has also gone up considerably because modern CPUs have so much more state and the mismatch between the ALU speed and the memory hierarchy have gotten worse.  Of course there are variations in microkernel design and how much context actually gets switched but I don't think the argument that the costs that were prohibitive in the 90s are now trivial is actually obvious.

Two other points to consider: computers are now "fast enough" for many but not all purposes and a bit of overhead is not always going to be prohibitive even if it is a significant fraction.

On the other hand, the force multiplier is much larger especially for one of the very few mainstream OS kernels.  If you can do a bit of development work to reduce context switches in IO and reduce overhead by 0.1% but you get to deploy that to a billion devices that's a big difference in aggregate. It still may or may not be worth it especially if you compromise correctness but it's worth considering.

[Marco]

The cost of TLB flushes went up. On the other hand PCID is now supported by both AMD and Intel.

[SiliconWizard]

Again, most current "mainstream" OS kernels are hybrid kernels (macOS, Windows.)
Linux is a bit an oddball with its monolithic structure. In that regard, Andrew was right. He wasn't so right in his claim that GNU Hurd would be the future. Yeah, not really.

But Linus's point was precisely to design something practical that would just work on commodity machines, and history quickly showed he was right.
It's a bit of a pragmatism vs. idealism approach.
Fun point about Andrew's "I wouldn't give you a good grade for this". So much for an OS that is running most servers, supercomputers and mobile devices in the world, that is decently secure and that has created probably directly and indirectly a multi-trillion dollar business worldwide over 30 years.

Pure microkernels do exist on well established systems, such as QNX.

More isolation would certainly be a good thing in any case. Yes, current hardware may still not be optimized for this, and possibly something to focus on first.

Heck, one thing that I still find mind-boggling, on a higher level, is using stacks that hold both data and return addresses. Merely changing that (which is not going to be a quick job though) would avoid a large chunk of exploits.