
KLOS: Kernel-Less Operating System Architecture (2005) [pdf] - vezzy-fnord
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.59.2606&rep=rep1&type=pdf
======
ridiculous_fish
Reading and trying to understand this:

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.

~~~
vezzy-fnord
You mostly have it right.

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.

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

------
nickpsecurity
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:

Tiara [http://dspace.mit.edu/bitstream/handle/1721.1/37589/MIT-
CSAI...](http://dspace.mit.edu/bitstream/handle/1721.1/37589/MIT-CSAIL-
TR-2007-028.pdf?sequence=1)

SAFE [http://www.crash-safe.org/assets/ieee-
hst-2013-paper.pdf](http://www.crash-safe.org/assets/ieee-hst-2013-paper.pdf)

~~~
agumonkey
Funny, Tom Knight (Lisp Machine cpu designer) suggested to read about crash-
safe.org work. Small world.

~~~
nickpsecurity
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. :)

~~~
agumonkey
Didn't know it was your work. Enjoy the trip ;)

~~~
nickpsecurity
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. :)

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

------
tux3
Unfortunately, I am being served an error about exceeding the "daily download
allowance", is there a mirror somewhere?

~~~
vezzy-fnord
Here you are:
[http://darknedgy.net/files/vasudevan_klos_05.pdf](http://darknedgy.net/files/vasudevan_klos_05.pdf)

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

------
vezzy-fnord
Page 2 diagram is blacked out for whatever reason, rest is fine.

~~~
Zr40
Diagram renders fine in Safari; here's a screenshot of the diagram:
[http://i.imgur.com/GoytjRf.png](http://i.imgur.com/GoytjRf.png)

------
listic
Does this have any running code?

