Quotes of the week

[Posted May 10, 2017 by corbet]

A long time ago I laughed when I saw that Microsoft had to do lots of "hardening" of their kernel to protect themselves from crappy drivers, as I knew we didn't have to do that because we had the source for them and could fix the root issues. But that has changed and now we don't all have that option.

— Greg Kroah-Hartman

I think the merge window is basically some kind of ultimate curse.

— Jon Masters

Quotes of the week

Posted May 11, 2017 17:22 UTC (Thu) by dgm (subscriber, #49227) [Link] (5 responses)

The CONFIG_PROTECT_FROM_CRAPPY_DRIVERS option proposed by Greg is, in essence, making Linux one (big) step closer to being a microkernel. Just add a fixed ABI (maybe message passing) and you're done. So, if you really are considering it you may as well do it properly. Any crappy out-of-tree driver certainly deserves to be punished with low performance.

Quotes of the week

Posted May 12, 2017 6:40 UTC (Fri) by gregkh (subscriber, #8) [Link] (4 responses)

No, it's not any steps closer to being what you think of as a "microkernel" at all, it's just enabling different types of checks for the existing internal api calls to try to protect the kernel from crappy out-of-tree driver code.

No need for any message-passing or fixed api at all, sorry.

Quotes of the week

Posted May 29, 2017 19:31 UTC (Mon) by ccurtis (guest, #49713) [Link] (3 responses)

Knowing nothing about the size of the task, would it be at all possible/reasonable to add a ring 1 layer where bad drivers could live? There's already something of a fixed API using EXPORT_SYMBOL(_GPL).

Quotes of the week

Posted May 30, 2017 8:16 UTC (Tue) by viro (subscriber, #7872) [Link] (2 responses)

*rotfl*

EXPORT_SYMBOL is NOT a fixed API. Not even close. Way too much is included into that pile to make any promises of that kind; it's a couple of decades of "export anything that moves" too late for that.

Not going to happen. What's more, that "interface" is full of "here's a pointer to object, go ahead, dereference it and chase pointers as you will", so even on x86 you couldn't put that into ring 1, not to mention the other architectures that do not duplicate that particular misfeature in the first place.

Quotes of the week

Posted May 31, 2017 13:31 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Even if it were, Ring 1 on x86 is almost the same as ring 3: the only real difference is that page protections can differ. In particular, all the privileged instructions that trap in ring 3 also trap in ring 1, requiring expensive privilege transitions to service: that includes, uh, direct hardware access, i.e. the sort of thing device drivers tend to do a lot.

There's a reason not many OS vendors used rings 1 and 2 for anything. (What were they originally intended for? I seem to recall IBM using ring 1 for something in OS/2: did they ask Intel to add more than the usual two rings? Were they inherited from some ancient computer that predates my parents' birth? :) )

Quotes of the week

Posted Jun 4, 2017 22:14 UTC (Sun) by flussence (guest, #85566) [Link]

I have an old 486 programming book that describes ring 1 as for “system services” and ring 2 for “custom extensions”, whatever that means. Going off those labels I could imagine it being used by a microkernel or hypervisor system. It doesn't name any real world examples unfortunately.

Reading some more of it, it sounds like these function more like ring 0 subsets than ring 3: only the latter gets page table entries with the user mode bit set, the rest don't and also have less restrictions on calling into each other's code. Most of these details go over my head but I get the general gist of it.

In a modern system, we have a different three-ring security circus: ring 1 was replaced by Docker and ring 2 by Electron.