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

91–100 of 199 posts

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

#91

Post by naasking »

acd wrote: post #70

There is a reason why kernel code run in privileged mode, speed! If you run more kernel code in privileged mode then you do not need to copy as much data between the kernel and user space. Vs a micro kernel you will have to copy more data up to user space. Copying data to user space causes context switches and gives less performance. Larger mono kernels: Speed Micro kernels have advantages such as: smaller privileged…

> If you run more kernel code in privileged mode then you do not need to copy as much data between the kernel and user space.

Microkernels don't copy data into the kernel address space, they copy data between userland address spaces. Which still happens in monolithic systems anyway when you're doing IPC. These are typically short messages, often only data passed in registers.

And if copying is going to be a bottleneck, then you negotiate a shared address space just like in Unix, and no more copying.

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

#92

Post by da_chicken »

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…

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

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

#93

Post by naasking »

nasoieu wrote: post #3

That chart with the growth of the Linux kernel discredits everything. The Linux kernel continues to grow because they are obsessed with keeping all drivers in mainline instead of having a stable API for them as any sane project would.

> That chart with the growth of the Linux kernel discredits everything.

What claim does it discredit exactly?

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

#94

Post by tlb »

pradn wrote: post #80
acd wrote: post #70

There is a reason why kernel code run in privileged mode, speed! If you run more kernel code in privileged mode then you do not need to copy as much data between the kernel and user space. Vs a micro kernel you will have to copy more data up to user space. Copying data to user space causes context switches and gives less performance. Larger mono kernels: Speed Micro kernels have advantages such as: smaller privileged…

Do you really need to do a full copy? What if you had a shared page and notified the user process when the data in the page was available at a certain offset. Take a look at this paper (FlexSC: Flexible System Call Scheduling with Exception-Less System Calls): https://www.usenix.org/legacy/event/osdi10/tech/full_papers/...

Sharing pages between user processes and kernel is extremely bug-prone, because threads in the user process can mutate the data while the kernel is reading it, leading to all kinds of race conditions. You can't depend on user processes respecting mutexes for security.

You can make this work by removing the page from the user process before making it available to the kernel, but the synchronization overhead of doing this (especially on a NUMA system) is probably worse than copying moderate amounts of data.

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

#95

Post by dkersten »

monocasa wrote: post #31
pjmlp wrote: post #16

Earlier quoted context omitted.

Lack of performance on microkernels is a myth nowadays. QNX and many embedded OS, some of which driving high integrity software, are all microkernel based. Including the one most likely handling the real time communication of this mobile radio.

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…

> It's not a myth.

As was posted elsewhere, they seem to be fast enough for games on the Nintendo Switch: https://news.ycombinator.com/item?id=17768537

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

#96

Post by Symmetry »

pjmlp wrote: post #58
nkkollaw wrote: post #10

Linux is the most popular OS in the world (of course, counting Android), so I guess this means it doesn't really matter is monolithic is flawed, or it is not flawed enough.

Sure it matters, because Android Oreo has actually forked Linux into a microkernel like design, where drivers run as separate processes and use Android IPC to talk with the kernel.

And Fuchsia, if it ends up replacing Android, is a microkernel design from the bottom up.

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

#97

Post by ysleepy »

pjmlp wrote: post #59
KMag wrote: post #45

Earlier quoted context omitted.

The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.

And what many seem to be unaware, is that project Treble made Android Linux into a microkernel where drivers use Android IPC to talk with the kernel. https://source.android.com/devices/architecture/kernel/modul... https://source.android.com/devices/architecture/hidl/ So everyone running Android Oreo or newer on their phones, not only has a microkernel on their basebase radio, they also have a Linux tamed into a micro…

I don't see a microkernel architecture here. Requiring drivers to be loadable modules is just arriving in the 1990s of monolithic kernels. Also, only new devices with SoCs introduced for Android 9 are required to use kernel modules and kernels newer than 3.18. [1]

This means most (updated) Android 8 devices in the field are not Project Treble and are running old-style module-less kernels and don't have A/B system partitions.

HALs only seem to be there to abstract over the APIs of different hardware implementations and access to them. Not necessarily their drivers.

I would love to be wrong about this, so I would really appreciate evidence to the contrary here.

[1] https://source.android.com/devices/architecture/kernel/modul...

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

#98

Post by monocasa »

dkersten wrote: post #95
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…

> It's not a myth. As was posted elsewhere, they seem to be fast enough for games on the Nintendo Switch: https://news.ycombinator.com/item?id=17768537

I mean, on the switch, the filesystem is incredibly slow, and the GPU drivers use a ported version of Linux's Nvidia DRM drivers that runs most of the driver in the same process as the user code. So the only place where they've really optimized for performance between subsystems, they took a more exokernel like model.

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

#99

Post by [deleted] »

bena wrote: post #33
andrewstuart2 wrote: post #13

Earlier quoted context omitted.

If parallel dimensions exist, then it's most certainly one of the closest dimensions to ours. If I'm sure of one thing, it's that as soon as we decided to build everything as Microkernels, we'd have the same squeaky wheels touting the massive benefits of Monotlithic OS design. We're hilariously cyclical in our preferences. "Think of all the runtime efficiencies of the shared memory, and how much easier it would be to…

I think it's just a matter of being deep in the weeds on whatever thing we're currently invested in. When we choose a direction, we see all the difficulties that path provides and kind of forget about all of the things it gives us. And when looking at the other option, we see all the things that would overcome our difficulties while assuming that we get to keep everything good from the current path. Everything is a t…

[deleted]

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

#100

Post by ysleepy »

swiley wrote: post #50

In a perfect wrold microkernel OSes would be perfect but then it's all pointless. In real life there are certain parts of the OS that have to work or the whole device stops working. Furthermore: the isolation of dynamic and less tested application code from these parts is generally a good idea, that's why monolithic OSes are so popular; they're simply less demanding.

Nobody claims faults of core functions must be survivable in microkernel designs. The restarting of driver processes is a nice trick, but in the end the isolation and clean interfacing are particularly useful in an imperfect world.

The goal is to minimize the trusted computing base (TCB) so that it is, at least to some degree, verifiably correct. Then tack on features using isolated components.

Post reply on HN