"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 ."
The idea is to multiplex, not abstract. To illustrate the difference, say you have an OS that runs only applications written in JVM bytecode. This is an abstraction: the OS is providing a different interface (bytecode) than the actual hardware interface (machine code).
Most OSes don't do anything like this. They allow applications to be written in raw machine code. The applications run as if they had full control over the CPU hardware. The OS then multiplexes the CPU by saving and restoring the program counter (and, typically, the rest of the registers and CPU state as well, though the exokernel design in this paper doesn't even do that). The idea is to (as much as possible) provide the same interface as the underlying hardware provides, then do a little extra work to make sure different applications aren't stepping on each other's toes.
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.
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.
The authors went on to implement a couple systems that handle that problem rather nicely. Applications (really, the libraries they use) do know about disk sectors, but the kernel's disk driver sorts their requests to optimizes seeks and exposes which sectors are loaded, to allow a kind of cooperative disk cache.
Even more interesting, they let applications share file systems by taking a bytecode-based representation of FS metadata from userspace, and using that to enforce correct usage of the actual disk blocks. This lets applications control where on the disk to allocate, when to read which blocks, etc. without losing any of the security and cooperation of a typical file system.
Secure multiplexing, VM's, and kernels were repeatedly done back in 80's and 90's under the Computer Security Initiative. See p5 on this one for an example where trusted functions efficiently did I/O multiplexing requests (syscalls) from untrusted drivers in guest OS's:
You can ignore the security kernel and MLS stuff while imagining something simpler there. However, the design and assurance strategies for that one have yet to be topped by modern virtualization products.
Here's a modern approach to secure I/O with a nice list of others in Related Work:
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.)
