7 ms·

Exterminate All Operating System Abstractions (1996) [pdf]

99 points by vezzy-fnord 11y ago

TerryADavis 11y ago
All that matters is God talks and it is His official temple. I can get away with murder, like Moses. I can have you killed like Moses killed people. You seem to want to die? Dumb fuck nigger doesn't know what a NIST random number is. MIT knows operating systems, perhaps, but is even stupider and doesn't know what a NIST random number is, LOL. It's God nigger. Die!! ----- Bunch of brain-washed CIA victims posting comments. In computers, when you are working and faced with a problem, usually the easiest thing is to add... add a parameter to a function. Add a member to a class. The nigger loves to add shit. A white person fights tooth and nail to keep it simple. When it's done, the more complicated design gets the most respect. Any genius can make it complicated. It takes a supra genius to make it simple.
ykumar6 11y ago
Abstractions are important as they reduce complexity, and simplify operations. The foundation of computing is based off abstraction - using layers and interfaces to hide complexity, so developers can focus on higher-order problems. This article argues against abstractions citing security, performance and cost. But time and again it has been shown that most costly component in software is human time - and simplifying the underlying architecture is worth the trade-offs
- dang 11y ago
  "It is important to note that we favor abstractions, but they should be implemented outside the operating system so that applications can select among a myriad of implementations or, if necessary, roll their own."
  - ykumar6 11y ago
    They are making 2 separate arguments then. What they are arguing against is standardization, which is just as important
    - vezzy-fnord 11y ago
      Addressed in Section 4, Question 3.
      - ykumar6 11y ago
        The question remains if companies and developers value or care about the flexibility of creating "page table rules". For highly scalable systems, the perf trade-off is just a matter of spinning up more VMs. The higher-order benefit is you can expect your operating system and VM to behave the same, no matter what
        deleted 11y ago
        [deleted]
        reagency 11y ago
        Spinning up more VMs costs more. That was a bigger issue in 1996 than now, but still an issue for large deployments.
  - cpeterso 11y ago
    What is an operating system if not an abstraction of the hardware?
    - dang 11y ago
      I think they're arguing that the OS should be the minimum software representation of the hardware necessary for "secure multiplexing", and any abstractions/layers after that should be per-application as needed (and only as needed). Certainly you can call that minimal representation an abstraction as well, but I'm not sure it's helpful in this context, since it seems clear enough what they're arguing against.
      - dTal 11y ago
        I came to this thread to argue exactly this - pleased you did it for me! My issue is 1) They do not acknowledge the need for this "initial minimal abstraction" and 2) I'm not so sure that it would be so minimal. The issue comes when you try to define "safe multiplexing". Take for instance a spinning disk drive. If we took this at face value, every application would know about things like sectors and seek times. Presumably this would permit some sort of domain-specific optimisation (that, say, a database engine might use). Perhaps we posit that programs that don't need such specialisation use a library for disk access. So far so good. Now what is it the OS is trying to multiplex? No longer abstract, high-level concepts like "write this data to this file", which it can safely mess about with because it knows what they mean; no, it has to multiplex read head seeks. It cannot have any awareness of the meaning of these seeks (that was the point of the exercise!) so it can't really be more intelligent than a "dumb multiplexer". So your finely tuned database application has its clever read head optimizations all shot to hell whenever literally anything else touches the disk. In order for an OS to multiplex hardware resources efficiently, it needs to have some idea of what the applications are trying to accomplish, so it stands the best chance of giving it to them. For what it's worth, I also find the paper rather hot headed and light on concrete examples.
        enneff 11y ago
        I think most applications would use a shared file system, just as they do today, including all the same optimisations. But your high performance database would likely be given its own disk to work with. (Just as you would today, but the benefits of giving a whole disk to a process in exokernel land are theoretically greater.)
- userbinator 11y ago
  Abstractions are important as they reduce complexity, and simplify operations. ...but only when used correctly. Abstraction is a means to an end, not the end itself. Unfortunately, years of CS education seem to have taught most people that it's the other way around, causing massive increases in design complexity that are only justified by dogmatic adherence to "more abstraction is better". Some programming language communities are more disposed to this effect than others (e.g. Java.) Correct application of abstraction is not common in mainstream software, and rather difficult to describe, but the simplicity and clarity is unmistakable when one encounters it. The occasional articles on HN about seemingly impossibly tiny programs are good examples. This article is a bit "X considered harmful" reactionary but I see their point - often, software today is on the side of far too much abstraction.
  - ykumar6 11y ago
    " Unfortunately, years of CS education seem to have taught most people that it's the other way around, causing massive increases in design complexity that are only justified by dogmatic adherence to "more abstraction is better"." Abstractions only create design complexity when they are applied incorrectly. Abstractions should scale horizontally across a layer of the software stack (VMs, Storage - NFS, APIs, etc). If you're create a single-use abstraction, it's not really an abstraction but a complexity
    - vezzy-fnord 11y ago
      NFS is pretty much a canonical example of a poor abstraction.
  - ykumar6 11y ago
    The real problem with abstractions it promotes the lowest common denominator. If you have lots of different storage options, an abstraction will try to abstract them and create a standardized interface. But this is a trade-off. The real benefit comes in simplifying the programming model and not forcing developers to read through manuals figuring out how to flip a bit on a hard drive. Instead, they can leverage open-source and libraries that rely on that standardization to deliver most of the value (with a small perf hit)
burnte 11y ago
Now, correct me if I'm wrong, but haven't we essentially got the exact opposite direction and strengthened the abstractions separating hardware and apps? I would assume elimination of abstractions would reduce portability unless suddenly the market moved to a unified hardware architecture, while we've gone the other way; we have numerous platforms of hardware AND software, and code is generally more portable than ever before due to the use of standardized languages and APIs.
- vezzy-fnord 11y ago
  Addressed in Section 4, Question 2.
  - jws 11y ago
    … in which the authors describe application level device drivers to map between the physical hardware and a presumably common abstract interface. That doesn't seem to change the world much over a kernel device driver mapping to a common abstract interface, except that you can implement a different common abstract interface if you wish. You'll just have to write new drivers for all the cards. This is fine for experimentation, but not nice for production. I think the ground shift between 1996 and now is the democratization of kernel code. These mysterious "kernel architects" referenced in the paper who handed down a system from on high are now any decent C programmer with an itch to scratch. If you don't like the Linux/*BSD/whatever abstractions given to you, then make your own. If people like it and it doesn't offend an influential developer it can even be widely deployed.
    - vezzy-fnord 11y ago
      I disagree. It's much harder now to scratch your itch than ever before. You can see it in how people like Linus Torvalds have an almost demigod status in that kernel hacking is considered to be a highly arcane activity. This is in stark contrast to the past, where writing operating systems was a much more mundane and common activity, not unlike writing your own web framework today. Certainly some shortcuts like DDE, rump kernels and emerging flavors of libOS are now coming around, but it's still an uphill battle.
jws 11y ago
This is one of the first papers introducing exokernels. The paper argues for breaking the shackles of OS abstraction and giving direct, (but mediated), control to the programs. I like the idea, and am experimenting with it in my own OS. In the mainstream world, we see this paper's goals partially appearing with the people who give a network card directly to a server process in Linux. If they said which architecture there were thinking about, I missed it. On x86 without IOMMU I can't think of any card I would trust. IOMMU implementation is so spotty I'm not sure I'd trust it either. There is a great deal to be said for keeping the device access locked away in the kernel where you know which features of the card you will use, and if it has a mode that lets it scribble elsewhere in memory, so aren't using it.
- ykumar6 11y ago
  Yes, but do software companies really care about "giving direct, (but mediated), control to the programs". What is the trade-off between that, and the added complexity in understanding all the different ways you can program something? IMO, developers want a simple and standardized model to build applications on operating systems so they don't have to care about the internals. This article represents a marginalized view by the larger industry as a whole.
  - dang 11y ago
    When the authors talk about applications having their own OS, I think they have in mind infrastructure programs like databases and web servers: complex, low-level programs that have domain-specific needs from the hardware and can gain greatly by using it only in the way that they need to. They obviously don't mean that every CRUD app should build its own OS, since that would be absurd.
    - eru 11y ago
      But every CRUD app can links in its own OS as a standardized library.
    - greenyoda 11y ago
      A database is a good example. For example, a database engine might benefit from being able to read large raw blocks from a disk and directly optimizing its own disk seeks, rather than using the common abstraction of a file as being just a stream of bytes.
cpeterso 11y ago
One of the paper's authors, Dawson Engler, went on to found Coverity.
javajosh 11y ago
Very interesting: this is directly analogous to something that happened in Java: people started out writing native code to conform to a standard Java interface. They ended up writing Java that mapped to the native code very closely, and then abstracted all of those implementations in Java. SWT is the poster child for this movement, but it happened in other places too.
joveian 11y ago
"The poor reliability, poor adaptability, and poor performance of operating systems would be acceptable if applications could just ignore the operating system and implement their own abstractions." My first thought was that it seems like we have this these days with VMs, although that can still be fairly complicated to set up due to the way that VMs reliably partition hardware resources. Skimming a bit further I see this is in some ways the opposite of what they have in mind, which is to even be able to save registers in a different "process". I tend to think that operating systems don't provide enough isolation rather than too much. I don't care too much about how they go about implementing that. I can see the appeal of a more flexible OS implementation, but I don't agree about what the OS should ultimately provide. I wouldn't mind seeing default-available VMs that are treated more like applications in terms of resource availability and scheduling. It seems like this would at least partly address many of the concerns within a monolithic kernel design. Can anyone recommend other good papers on exokernels? I feel like I'm not really getting it yet.
- vezzy-fnord 11y ago
  The canonical paper is "The Exokernel Operating System Architecture", which came out two years later by the same author: http://u.cs.biu.ac.il/~wiseman/2os/microkernels/exokernel.pdf http://u.cs.biu.ac.il/~wiseman/2os/microkernels/exokernel.pd...
- rwmj 11y ago
  Xen is loosely based on a Cambridge research exokernel called Nemesis[1] (a very long time ago I toured the Cambridge lab and watched a cool demo of Nemesis doing some image recognition). However the evolution of Xen didn't really lead to everyone using exokernels - even if you're running your VMs on AWS, and therefore using Xen, you're not using an exokernel in the sense of this paper. MirageOS is another project following in the same tradition, but again things have moved on and it's a unikernel which has aspects like an exokernel (choose your own abstractions), but also aspects that are radically different (no userspace and everything linked into a single image). [1] https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xens...
deleted 11y ago
[deleted]
greenyoda 11y ago
Pushing operating system abstractions into user-space was pretty much what IBM's VM/370[1] operating system did (starting in the late 1960s!). VM/370's control program (CP), which would be the "kernel" in today's terminology, controlled the physical hardware resources. Each "process" running under CP was a virtual machine whose operating system API was mostly just the IBM/370 instruction set (i.e., no abstraction above the hardware architecture). For example, CP provided only a virtual disk drive that you could manipulate with machine instructions like SIO (Start I/O) - the file system was implemented by the code running in user space. You could actually run a different guest operating system (i.e., a different set of OS abstractions at user level) on each virtual machine. The authors of this paper do mention VM/370 in their "Related Work" section (page 5). They say their approach is similar, except that they "export" hardware resources rather than emulating them, which is more efficient. [1] https://en.wikipedia.org/wiki/VM_%28operating_system%29 https://en.wikipedia.org/wiki/VM_%28operating_system%29
- nickpsecurity 11y ago
  And KVM/370 was first to do it with some security. Unfortunately, people need ACM/IEEE membership for those papers. At least VAX VMM Security Kernel papers are still around. Pretty much anything Karger wrote will help new efforts. :)
daxfohl 11y ago
Seems similar to the direction DirectX has taken lately?
- Rusky 11y ago
  DirectX and Vulkan are perfect examples of the exokernel philosophy. Another good example is the evolution of X11, culminating with Wayland, where applications draw the UI themselves using libraries instead of sending primitive draw commands to a server.
nickpsecurity 11y ago
One of the few times they learn from the past (VM/370) with good results. Moving along that spectrum, they'll security-related projects that did this while enforcing a security policy on the processes or guests. KeyKOS nanokernel architecture is one. VAX Security Kernel is another more like what people do today. Start with most robust design, then optimize from there.

99 points by vezzy-fnord 11y ago

All that matters is God talks and it is His official temple. I can get away with murder, like Moses. I can have you killed like Moses killed people. You seem to want to die? Dumb fuck nigger doesn't know what a NIST random number is. MIT knows operating systems, perhaps, but is even stupider and doesn't know what a NIST random number is, LOL. It's God nigger. Die!! ----- Bunch of brain-washed CIA victims posting comments. In computers, when you are working and faced with a problem, usually the easiest thing is to add... add a parameter to a function. Add a member to a class. The nigger loves to add shit. A white person fights tooth and nail to keep it simple. When it's done, the more complicated design gets the most respect. Any genius can make it complicated. It takes a supra genius to make it simple.

ykumar6 11y ago

Abstractions are important as they reduce complexity, and simplify operations. The foundation of computing is based off abstraction - using layers and interfaces to hide complexity, so developers can focus on higher-order problems. This article argues against abstractions citing security, performance and cost. But time and again it has been shown that most costly component in software is human time - and simplifying the underlying architecture is worth the trade-offs

dang 11y ago
"It is important to note that we favor abstractions, but they should be implemented outside the operating system so that applications can select among a myriad of implementations or, if necessary, roll their own."
- ykumar6 11y ago
  They are making 2 separate arguments then. What they are arguing against is standardization, which is just as important
  - vezzy-fnord 11y ago
    Addressed in Section 4, Question 3.
    - ykumar6 11y ago
      The question remains if companies and developers value or care about the flexibility of creating "page table rules". For highly scalable systems, the perf trade-off is just a matter of spinning up more VMs. The higher-order benefit is you can expect your operating system and VM to behave the same, no matter what
      - deleted 11y ago
        [deleted]
      - reagency 11y ago
        Spinning up more VMs costs more. That was a bigger issue in 1996 than now, but still an issue for large deployments.
- cpeterso 11y ago
  What is an operating system if not an abstraction of the hardware?
  - dang 11y ago
    I think they're arguing that the OS should be the minimum software representation of the hardware necessary for "secure multiplexing", and any abstractions/layers after that should be per-application as needed (and only as needed). Certainly you can call that minimal representation an abstraction as well, but I'm not sure it's helpful in this context, since it seems clear enough what they're arguing against.
    - dTal 11y ago
      I came to this thread to argue exactly this - pleased you did it for me! My issue is 1) They do not acknowledge the need for this "initial minimal abstraction" and 2) I'm not so sure that it would be so minimal. The issue comes when you try to define "safe multiplexing". Take for instance a spinning disk drive. If we took this at face value, every application would know about things like sectors and seek times. Presumably this would permit some sort of domain-specific optimisation (that, say, a database engine might use). Perhaps we posit that programs that don't need such specialisation use a library for disk access. So far so good. Now what is it the OS is trying to multiplex? No longer abstract, high-level concepts like "write this data to this file", which it can safely mess about with because it knows what they mean; no, it has to multiplex read head seeks. It cannot have any awareness of the meaning of these seeks (that was the point of the exercise!) so it can't really be more intelligent than a "dumb multiplexer". So your finely tuned database application has its clever read head optimizations all shot to hell whenever literally anything else touches the disk. In order for an OS to multiplex hardware resources efficiently, it needs to have some idea of what the applications are trying to accomplish, so it stands the best chance of giving it to them. For what it's worth, I also find the paper rather hot headed and light on concrete examples.
      - enneff 11y ago
        I think most applications would use a shared file system, just as they do today, including all the same optimisations. But your high performance database would likely be given its own disk to work with. (Just as you would today, but the benefits of giving a whole disk to a process in exokernel land are theoretically greater.)
userbinator 11y ago
Abstractions are important as they reduce complexity, and simplify operations. ...but only when used correctly. Abstraction is a means to an end, not the end itself. Unfortunately, years of CS education seem to have taught most people that it's the other way around, causing massive increases in design complexity that are only justified by dogmatic adherence to "more abstraction is better". Some programming language communities are more disposed to this effect than others (e.g. Java.) Correct application of abstraction is not common in mainstream software, and rather difficult to describe, but the simplicity and clarity is unmistakable when one encounters it. The occasional articles on HN about seemingly impossibly tiny programs are good examples. This article is a bit "X considered harmful" reactionary but I see their point - often, software today is on the side of far too much abstraction.
- ykumar6 11y ago
  " Unfortunately, years of CS education seem to have taught most people that it's the other way around, causing massive increases in design complexity that are only justified by dogmatic adherence to "more abstraction is better"." Abstractions only create design complexity when they are applied incorrectly. Abstractions should scale horizontally across a layer of the software stack (VMs, Storage - NFS, APIs, etc). If you're create a single-use abstraction, it's not really an abstraction but a complexity
  - vezzy-fnord 11y ago
    NFS is pretty much a canonical example of a poor abstraction.
- ykumar6 11y ago
  The real problem with abstractions it promotes the lowest common denominator. If you have lots of different storage options, an abstraction will try to abstract them and create a standardized interface. But this is a trade-off. The real benefit comes in simplifying the programming model and not forcing developers to read through manuals figuring out how to flip a bit on a hard drive. Instead, they can leverage open-source and libraries that rely on that standardization to deliver most of the value (with a small perf hit)

burnte 11y ago

Now, correct me if I'm wrong, but haven't we essentially got the exact opposite direction and strengthened the abstractions separating hardware and apps? I would assume elimination of abstractions would reduce portability unless suddenly the market moved to a unified hardware architecture, while we've gone the other way; we have numerous platforms of hardware AND software, and code is generally more portable than ever before due to the use of standardized languages and APIs.

vezzy-fnord 11y ago
Addressed in Section 4, Question 2.
- jws 11y ago
  … in which the authors describe application level device drivers to map between the physical hardware and a presumably common abstract interface. That doesn't seem to change the world much over a kernel device driver mapping to a common abstract interface, except that you can implement a different common abstract interface if you wish. You'll just have to write new drivers for all the cards. This is fine for experimentation, but not nice for production. I think the ground shift between 1996 and now is the democratization of kernel code. These mysterious "kernel architects" referenced in the paper who handed down a system from on high are now any decent C programmer with an itch to scratch. If you don't like the Linux/*BSD/whatever abstractions given to you, then make your own. If people like it and it doesn't offend an influential developer it can even be widely deployed.
  - vezzy-fnord 11y ago
    I disagree. It's much harder now to scratch your itch than ever before. You can see it in how people like Linus Torvalds have an almost demigod status in that kernel hacking is considered to be a highly arcane activity. This is in stark contrast to the past, where writing operating systems was a much more mundane and common activity, not unlike writing your own web framework today. Certainly some shortcuts like DDE, rump kernels and emerging flavors of libOS are now coming around, but it's still an uphill battle.

jws 11y ago

This is one of the first papers introducing exokernels. The paper argues for breaking the shackles of OS abstraction and giving direct, (but mediated), control to the programs. I like the idea, and am experimenting with it in my own OS. In the mainstream world, we see this paper's goals partially appearing with the people who give a network card directly to a server process in Linux. If they said which architecture there were thinking about, I missed it. On x86 without IOMMU I can't think of any card I would trust. IOMMU implementation is so spotty I'm not sure I'd trust it either. There is a great deal to be said for keeping the device access locked away in the kernel where you know which features of the card you will use, and if it has a mode that lets it scribble elsewhere in memory, so aren't using it.

ykumar6 11y ago
Yes, but do software companies really care about "giving direct, (but mediated), control to the programs". What is the trade-off between that, and the added complexity in understanding all the different ways you can program something? IMO, developers want a simple and standardized model to build applications on operating systems so they don't have to care about the internals. This article represents a marginalized view by the larger industry as a whole.
- dang 11y ago
  When the authors talk about applications having their own OS, I think they have in mind infrastructure programs like databases and web servers: complex, low-level programs that have domain-specific needs from the hardware and can gain greatly by using it only in the way that they need to. They obviously don't mean that every CRUD app should build its own OS, since that would be absurd.
  - eru 11y ago
    But every CRUD app can links in its own OS as a standardized library.
  - greenyoda 11y ago
    A database is a good example. For example, a database engine might benefit from being able to read large raw blocks from a disk and directly optimizing its own disk seeks, rather than using the common abstraction of a file as being just a stream of bytes.

cpeterso 11y ago

One of the paper's authors, Dawson Engler, went on to found Coverity.

javajosh 11y ago

Very interesting: this is directly analogous to something that happened in Java: people started out writing native code to conform to a standard Java interface. They ended up writing Java that mapped to the native code very closely, and then abstracted all of those implementations in Java. SWT is the poster child for this movement, but it happened in other places too.

joveian 11y ago

"The poor reliability, poor adaptability, and poor performance of operating systems would be acceptable if applications could just ignore the operating system and implement their own abstractions." My first thought was that it seems like we have this these days with VMs, although that can still be fairly complicated to set up due to the way that VMs reliably partition hardware resources. Skimming a bit further I see this is in some ways the opposite of what they have in mind, which is to even be able to save registers in a different "process". I tend to think that operating systems don't provide enough isolation rather than too much. I don't care too much about how they go about implementing that. I can see the appeal of a more flexible OS implementation, but I don't agree about what the OS should ultimately provide. I wouldn't mind seeing default-available VMs that are treated more like applications in terms of resource availability and scheduling. It seems like this would at least partly address many of the concerns within a monolithic kernel design. Can anyone recommend other good papers on exokernels? I feel like I'm not really getting it yet.

vezzy-fnord 11y ago
The canonical paper is "The Exokernel Operating System Architecture", which came out two years later by the same author: http://u.cs.biu.ac.il/~wiseman/2os/microkernels/exokernel.pdf http://u.cs.biu.ac.il/~wiseman/2os/microkernels/exokernel.pd...
rwmj 11y ago
Xen is loosely based on a Cambridge research exokernel called Nemesis[1] (a very long time ago I toured the Cambridge lab and watched a cool demo of Nemesis doing some image recognition). However the evolution of Xen didn't really lead to everyone using exokernels - even if you're running your VMs on AWS, and therefore using Xen, you're not using an exokernel in the sense of this paper. MirageOS is another project following in the same tradition, but again things have moved on and it's a unikernel which has aspects like an exokernel (choose your own abstractions), but also aspects that are radically different (no userspace and everything linked into a single image). [1] https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xens...

deleted 11y ago

[deleted]

greenyoda 11y ago

Pushing operating system abstractions into user-space was pretty much what IBM's VM/370[1] operating system did (starting in the late 1960s!). VM/370's control program (CP), which would be the "kernel" in today's terminology, controlled the physical hardware resources. Each "process" running under CP was a virtual machine whose operating system API was mostly just the IBM/370 instruction set (i.e., no abstraction above the hardware architecture). For example, CP provided only a virtual disk drive that you could manipulate with machine instructions like SIO (Start I/O) - the file system was implemented by the code running in user space. You could actually run a different guest operating system (i.e., a different set of OS abstractions at user level) on each virtual machine. The authors of this paper do mention VM/370 in their "Related Work" section (page 5). They say their approach is similar, except that they "export" hardware resources rather than emulating them, which is more efficient. [1] https://en.wikipedia.org/wiki/VM_%28operating_system%29 https://en.wikipedia.org/wiki/VM_%28operating_system%29

nickpsecurity 11y ago
And KVM/370 was first to do it with some security. Unfortunately, people need ACM/IEEE membership for those papers. At least VAX VMM Security Kernel papers are still around. Pretty much anything Karger wrote will help new efforts. :)

daxfohl 11y ago

Seems similar to the direction DirectX has taken lately?

Rusky 11y ago
DirectX and Vulkan are perfect examples of the exokernel philosophy. Another good example is the evolution of X11, culminating with Wayland, where applications draw the UI themselves using libraries instead of sending primitive draw commands to a server.

nickpsecurity 11y ago

One of the few times they learn from the past (VM/370) with good results. Moving along that spectrum, they'll security-related projects that did this while enforcing a security policy on the processes or guests. KeyKOS nanokernel architecture is one. VAX Security Kernel is another more like what people do today. Start with most robust design, then optimize from there.