KLOS: Kernel-Less Operating System Architecture (2005) [pdf]
citeseerx.ist.psu.edu
citeseerx.ist.psu.edu
1. The address space for each process has an unprivileged "user-level" segment (DSAPP), and a privileged "OS" segment (DSOS) where the data traditionally associated with the kernel is stored.
2. Traditional "system calls" are implemented as ordinary procedures. These procedures switch to the privileged segment, do their stuff, and then switch back to the user segment.
3. Since these are ordinary procedures, what's to prevent application code from switching to the privileged segment and mucking with the OS guts? Well, the app doesn't know which segment is privileged! It can try to read it out of the "system call" procedures, but that memory is execute-only, so that won't work.
4. Maybe the app determines the privileged segment via guess-and-check! To prevent that, the OS plays shell games, switching which segment is privileged around every time the app guesses wrong.
5. Ok, so there aren't that many segments: the probability of guessing right is still ~.01% per try. That's very unlikely, assuming the app only guesses once. (We hope attackers haven't thought of guessing more than once.)
This guess-and-check attack would seem to be a deal-breaker, no? This seems like a terribly insecure design.
It's mostly a PoC for a nokernel architecture, and a rather admirable affront at taming the darker corners of x86 segmentation to create a system where you have a per-address space "event core" rather than a traditional kernel, thus largely not performing so much as multiplexing. Though, I think an important addendum is that the selector relocation is context-global and thus the probabilistic mitigation cannot be thwarted by spacing the workload across threads.
----
(EDIT: Actually, I just reread it and in fact the event core will terminate a process after three successive "segment not present" faults, so that should be effective.)
----
By their testimony it is not any more susceptible to standard memory corruption errors than traditional monolithic OSes. One could then argue that the probabilistic weakness requires a malicious application that higher level security policy could weed out, but even further that the value added of a nokernel exceeds the downside of this hole relative to the monolithic kernel state of the industry which is already susceptible to a host of other vulnerabilities. It would, however, discount this KLOS in particular from any high-assurance use cases, but again so are monolithic kernels to begin with.
I think the gist of this is that the nokernel architecture is viable, but perhaps COTS architectures are not that expressive. Certainly not x86 it seems.
Tiara http://dspace.mit.edu/bitstream/handle/1721.1/37589/MIT-CSAI...
SAFE http://www.crash-safe.org/assets/ieee-hst-2013-paper.pdf
I really like it when people use the segment architecture to do something interesting. It forces people to really think about the question... what is a kernel?
Also, their technique of mapping the TSS I/O bitmap to virtual memory is clever.
Firefox has been falling behind of late. Every third website seems to have a huge banner video these days, and firefox chooses to run them automatically, and it can't seem to do so snappily. Makes the entire UI unresponsive, including the chrome outside that tab. Google maps is unusable on firefox as well for several months. Many are the flash videos that my firefox can't run because they changed some default and I can't be arsed to locate it. I just switch to chrome, which seems to handle them without problems using the same supposedly-insecure flash plugin.
(I'm on linux.)