The Jury Is In: Monolithic OS Design Is Flawed [pdf] • Hacker News Board

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

#111

Post by monocasa » Wed, Aug 15, 2018, 8:33 PM UTC

pjmlp wrote: post #85

monocasa wrote: post #79

Earlier quoted context omitted.

Certainly looks supported by /dev/radeon, just not /dev/amdgpu.

I didn't said it wasn't supported, I said: > My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04. Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos. And then there is this, "For one, AMD users can’t use applications that require OpenG…

OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support.

I really fail to see how that has anything to do with Linux's unstable kernel driver API.

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

#112

Post by gjm11 » Wed, Aug 15, 2018, 8:42 PM UTC

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

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

#113

Post by pjmlp » Wed, Aug 15, 2018, 8:46 PM UTC

monocasa wrote: post #111

pjmlp wrote: post #85

Earlier quoted context omitted.

I didn't said it wasn't supported, I said: > My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04. Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos. And then there is this, "For one, AMD users can’t use applications that require OpenG…

OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support. I really fail to see how that has anything to do with Linux's unstable kernel driver API.

Given that the radeon driver doesn't provide the same feature set as fglrx used to provide, with the same stability, it is surely a driver issue.

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

#114

Post by hinkley » Wed, Aug 15, 2018, 8:47 PM UTC

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…

Code doesn't run faster because it's in the kernel. The speed you're talking about comes from avoiding transitions in and out of a given space. If you stay out or stay in the results are pretty similar.

Except for your tooling. Cloudflare article from a couple years ago on why they don't use user-space network stack: https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp... and the tl:dr is a profound lack of feature parity. They use everything from iptables to tcpdump. If someone else worked on feature parity (they say it's too expensive for too small a gain for them), I expect they'd change their tune.

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

#115

Post by monocasa » Wed, Aug 15, 2018, 8:55 PM UTC

pjmlp wrote: post #113

monocasa wrote: post #111

Earlier quoted context omitted.

OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support. I really fail to see how that has anything to do with Linux's unstable kernel driver API.

Given that the radeon driver doesn't provide the same feature set as fglrx used to provide, with the same stability, it is surely a driver issue.

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

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

#116

Post by scintill76 » Wed, Aug 15, 2018, 8:56 PM UTC

pjmlp wrote: post #106

ysleepy wrote: post #97

Earlier quoted context omitted.

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 par…

Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shar…

I'll admit to not being steeped in the terminology, so feel free to educate me.. but some quick Googling suggests nobody else has called Treble a "microkernel." There are hits about Fuchsia (a totally separate OS), and some Android forks on microkernels.

I'm guessing that the Treble modules expose the traditional /dev and /sys interfaces like before, and these new HALs talk to devices through those, right? Is that not still a runtime-linked monolith, with fairly-thin userspace services between the kernel and the framework?

The bulk of driver code logic (e.g. interfacing with a touchscreen controller) is probably still running in the kernel - show me if I'm wrong. I would think this would be how you define a microkernel. One exception may be the GPU -- those drivers are often very thin in the kernel because of GPL, with a fat userspace library that they can legally keep closed-source.

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

#117

Post by Steko » Wed, Aug 15, 2018, 9:10 PM UTC

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…

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.

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

#118

Post by SkyMarshal » Wed, Aug 15, 2018, 9:12 PM UTC

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

It would be the dimension where Andrew Tannenbaum licensed Minix3 under a Free license back before Linus hacked up his own monolithic kernel version.

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

#119

Post by nine_k » Wed, Aug 15, 2018, 9:18 PM UTC

naasking wrote: post #84

badpun wrote: post #81

Earlier quoted context omitted.

Security, performance, ease of use.

I don't see why any of those are mutually exclusive. Capability based operating systems provide least privilege security, experiments with capability-based UIs have shown they are quite intuitive and secure because they align user actions with explicit access grants, and they don't perform any worse than monolithic or microkernel operating systems. The problems are really the flawed mental models people insist on bri…

Capability chains are relatively more expensive to check than a bitmask, or just nothing (as e.g. in an embedded system). Also, performance asks for shortest code paths and out-of-order execution, security asks for prevention of timing attacks and Spectre-like attacks.

Security requires to identify yourself with hard-to-fake means, it takes time and effort (recollecting and typing a password, fumbling with a 2FA token); ease of use asks for trusting and immediate response (light switch, tv, etc).

Performance asks for uninterrupted execution and scheduling of tasks based on throughput; ease of use asks for maximum resources given to the interactive application, and scheduling based on lowest interactive latency.

Also feature set vs source code observability, simplicity vs configurability, performance vs modularity, build time vs code size vs code speed, etc.

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

#120

Post by pradn » Wed, Aug 15, 2018, 9:22 PM UTC

tlb wrote: post #94

pradn wrote: post #80

Earlier quoted context omitted.

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 t…

Hmm. Perhaps temporarily switching the TLB entry to read-only mode for that page during kernel accesses? There might be some interesting software-hardware co-design solutions here.