So, they've looked at a sample of exploits that were critical on Linux and established that most wouldn't have been critical on a hypothetical otherwise-similar microkernel system.

But they haven't looked at a sample of exploits that were critical on an actual microkernel OS and seen how many would have been less serious (or not arisen) on a hypothetical otherwise-similar monolithic-kernel system.

It reminds me of a nice observation in "Surely you're joking, Mr Feynman". Feynman developed some nonstandard ways of solving mathematical problems. Other people came to him and he repeatedly solved problems they'd been stuck on. "He must be much smarter than us!" But the problems they brought to him were selected as ones they couldn't do, so of course he'd look better than them on those. They never bothered asking him problems he couldn't do but they could, because they'd already done them.

Now, maybe the authors of the paper are confident that there's no way that a microkernel design could encourage or exacerbate vulnerabilities. But so far as I can see they don't offer any actual argument for that proposition.

"But they haven't looked at a sample of exploits that were critical on an actual microkernel OS and seen how many would have been less serious (or not arisen) on a hypothetical otherwise-similar monolithic-kernel system."

Cuz they don't exist so far. Microkernel-based systems will have same kinds of bugs as monoliths if coded in same language for same hardware. From there, the microkernel architecture leads less bugs in number (less code), less in severity (more isolation), and sometimes less difficulty in patching or recovery. If looking for microkernel-based bugs, I'd look for errors in concurrency and passing data over IPC. Monolithic system are using more concurrency and middleware than ever now, though. Even more than microkernels from what I see if talking about all the strategies and their implementations vs a few, standardized primitives. So, even those areas central to microkernel design seem like problems shared with modern monoliths.

So, the status quo is that the monoliths mostly add problems and increase their severity. Vice versa, the microkernels mostly subtract them in number and/or severity. The field evidence shows this with most of the data on bugs and vulnerability coming from monolith users. From there, someone might want to try to see if the opposite is true. Burden of proof is on them, though, with the status quo being quite reasonable. And that investigation, as I said, might find "microkernel" problems that hold in how modern monoliths are used (esp service and web architectures). Still worth attempting since they might surprise us with what they find. :)

To be clear, that's all about the architectural patterns. I think combining all the potential benefits of microkernels in a system vs a simple monolith could lead to more bugs in microkernel. Most of the problems in software will come from complexity and QA level regardless of architectural style. So, my post is written with assumption that we're talking about large, complex systems done with one style or the other.

> The title is missing "from a security standpoint".

I mean, kind of, but since maintaining system security and integrity is a core function of the OS -- in fact, it is the primary gatekeeper in terms of all system security -- it means that "being secure" and "being correct" are often synonymous terms for an operating system.

After all, if we don't care about security at all we can all run CP/M or run everything as root.

Now, sure, you can say that the whole thing is bullshit because verified microkernels are so difficult to design that the end result would be an unusable system, but all that suggests is that when you design your kernel you should aim for a hybrid and compromise more on the side of a microkernel where you can.

The age old joke about the computer encased in concrete at the bottom of the ocean does indeed come to mind.

It would be more credible if the authors were able to distinguish between exploit and vulnerability.

I examined all fatal car crashes in the United States between pi day and Bloomsday in 2015 and assigned them a Mitigation Score based on the hypothetical that the people involved were instead walking. 98.3% of fatalities would have been prevented. The jury is in: ban all horseless carriages.