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.
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.