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.
it's not effective. you can just start another process and try again right? i think after 16k attempts you have about 2/3 chance of succeeding. kind of cool but not secure.
Darn, that's two good ones you given me to review in one day. Officially on my backlog. People interested in kernel-less OS's might also want to look at Tiara and its successor SAFE:
That is a trip. LISP machines were doing tagged memory and GC before most of them. Knight agreeing that SAFE is great work is a sign Im on right track. :)
SAFE is not my work. I was evangelizing many of the same principles, working similar things, and generally try to draw mainstream attention the The Right Thing (eg SAFE) when it manifests for a given problem/domain. High assurance security & systems path has been quite a trip, though. Thanks. :)
I've read through the paper, and while I understand how the operating system achieves memory protection (by using W^X flags and memory segmentation), I don't understand how the scheduler would work in a kernel-less OS. What prevents my program from hogging all of the system resources, and preventing other programs from executing?
vezzy - thanks for posting! You do not disappoint :-)
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.
On Win8.1, Firefox (Nightly 45.0a1) loads up the PDF and all illustrations without difficulty. Haven't tried on other platforms. Of course, now what's left to do is reading the article...
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.