Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Jury Is In: Monolithic OS Design Is Flawed [pdf]

ts.data61.csiro.au

Post reply on HN
Print view View original

131–140 of 199 posts

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#131

Post by monocasa »

pjmlp wrote: post #130
monocasa wrote: post #115

Earlier quoted context omitted.

... a brand new, mainline kernel will run fglrx just fine. It's user space (specifically the x srever) that decided to break fglrx. So how is that the fault of the kernel's unstable API again?

Graphics drivers run on the kernel.

I mean, everything runs on the kernel... but I assume you meant in the kernel.

Graphics drivers are split into three main pieces these days.

1) Kernel space that mainly sets up the GPU's MMU, and adds a context to the GPU's hardware thread scheduler. There'll be some modesetting too, but that piece is really simple (and fglrx never used the main kernel API for that anyway, so it doesn't really matter if it was stable or not. But it actually was pretty stable over the time frame we're talking about).

This piece still works fine on fglrx with a modern kernel.

2) A userspace component that lives with the window manager setting up the actual display output, and accelerating compositing. Stuff like EGL works by making IPC calls to this layer.

This is the piece that broke in your case, and only because the x server decided to change.

3) Another piece that runs in userspace and is ultimately what gets called by graphics APIs and is linked into every process making graphics calls. This is the vast majority of the driver.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#132

Post by nickpsecurity »

gjm11 wrote: post #112
imglorp wrote: post #2

The title is missing "from a security standpoint". Of course, everything is a tradeoff. TLDR: > We have presented what is, to the best of our knowledge, the first quantitative empirical assessment of the security implications of operating system structure, i.e. monolithic vs microkernel-based design. > Our results provide very strong evidence that operating- system structure has a strong effect on security. 96% of cr…

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…

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

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#133

Post by jacquesm »

The jury was in in the mid 1990's, but Linus Torvalds doesn't know when he's wrong and to listen to his betters. Linux succeeded because of its community, not because of its architecture. QnX has shown the strength of microkernels for decades, they are far more stable and much easier to work on than monoliths. The (small) speed penalty should be well worth the price of admission.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#135

Post by nostrademons »

justicezyx wrote: post #134

Now it's a good time to revive microkernel for prime as server less offers the abstraction for making transition transparent to users and application developers. Anyone tried that?

Much of the cloud/virtualization industry is actually built on exokernels; a hypervisor is basically the commercially-viable version of an exokernel. The unikernel movement is an attempt to revive the LibOS and use exokernels as they were originally designed (i.e. move OS abstractions into user-space and not have a whole OS running on top of an OS), but there've been several pragmatic barriers that've kept them from gaining all that much adoption.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#136

Post by ahartmetz »

nickpsecurity wrote: post #108
monocasa wrote: post #31

Earlier quoted context omitted.

It's not a myth. Real time doesn't mean fast, it just means deterministic. And I'll throw out there that many times the the term microkernel in a lot of embedded OSs has been contorted by marketing speak into something unrecognizable. Basically if you have multiple threads in the kernel, structure the kernel code into modules (but perhaps don't even allow dynamic loading of modules), and can communicate through async…

Blackberry Playbook was QNX-based. Performed better than iPad: https://www.youtube.com/watch?v=PYZDl4RNEVE Maybe they had some stuff in kernel mode in there. They still show you can start with a microkernel as the baseline then optimize from there retaining the architecture with its benefits in average case or most cases.

The BB10 phones were just as amazing as the Playbook - the UI was oh so smooth and responsive. I'd still be using my Q10 if it had more native apps or better Android compatibility.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#138

Post by nickpsecurity »

ahartmetz wrote: post #136
nickpsecurity wrote: post #108

Earlier quoted context omitted.

Blackberry Playbook was QNX-based. Performed better than iPad: https://www.youtube.com/watch?v=PYZDl4RNEVE Maybe they had some stuff in kernel mode in there. They still show you can start with a microkernel as the baseline then optimize from there retaining the architecture with its benefits in average case or most cases.

The BB10 phones were just as amazing as the Playbook - the UI was oh so smooth and responsive. I'd still be using my Q10 if it had more native apps or better Android compatibility.

One problem with Android is little delays that happen while typing. I thought a QNX-based platform could avoid that if they made sure UI parts were given adequate time slices. Was there any typing lag in those products?

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#139

Post by snaky »

pweissbrod wrote: post #8

I wonder if there exists a parallel dimension where linux is microkernel design and folks are pushing for monolothic citing the driver friendliness and performance

https://yarchive.net/comp/microkernels.html

edit added

> Guys, there is a _reason_ why microkernels suck. This is an example of how things are _not_ "independent". The filesystems depend on the VM, and the VM depends on the filesystem. You can't just split them up as if they were two separate things (or rather: you _can_ split them up, but they still very much need to know about each other in very intimate ways).

https://yarchive.net/comp/linux/user_space_filesystems.html

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#140

Post by iamcreasy »

jacquesm wrote: post #133

The jury was in in the mid 1990's, but Linus Torvalds doesn't know when he's wrong and to listen to his betters. Linux succeeded because of its community, not because of its architecture. QnX has shown the strength of microkernels for decades, they are far more stable and much easier to work on than monoliths. The (small) speed penalty should be well worth the price of admission.

> QnX has shown the strength of microkernels for decades

Could you elaborate on this one please?

Post reply on HN