Having seen SPIN's approach to extensibility, now we will look at Exokernel's
approach to operating system extensibility. The
name, Exokernel, itself comes from the
fact that the kernel exposes hardware
explicitly to the operating system extensions
living above it. The basic idea in Exokernel, is to decouple authorization
of the hardware from its actual use. let's say
you want to do research in my lab. I
may interview you, and once we're on the same
page, I'll give you a key to the lab. And
the resources you need in order to do work
in the lab. Mm, example, laptop, servers and so
on. Then I get out of the way. When
you actually use the resources, that's exactly the same idea
in Exokernel. Library operating system asks for a resource. Exokernel will
validate the request for the resource from the library. And bind the request
to the specific hardware resource. In
other words, Exokernel exposes the hardware
that was requested by the Library OS through creating a secure binding between
the ask and the actual hardware resource. Once Exokernel has established
this binding, it creates an encrypted key for the resource, and gives it to
the requesting library operating system. Similar to the analogy that I gave
you, of a student using my lab resources, the semantics of how the resource
is going to be used by the library is entirely up to the library.
Of course, within the norm of accepted use, similar to what I may impose
as certain restrictions or rules of behavior
that students have to observe in the
lab. Same way, there are certain accepted
norms for the user's resource that Exokernel may
have imposed. And so long as the
library operating system is staying within those norms,
then the semantics of how a particular
hardware resource is used is entirely up to
the library operating system. Once a library
operating system has asked for a resource and
Exokernel has created the binding for that
resource to the requesting library operating system, then,
the operating system is now ready to use the resource. Now, how does it use
the resource? Basically, what the library operating
system will do is present the encrypted key
that is received, authenticating that use of
the resource for this library to the Exokernel.
In other words, Exokernel will be able
to validate whether the key presented to it,
is the key that was presented for this particular
libraries operating system. So in other words, the key
cannot be forged, cannot be passed around. If I
gave a key to this library operating system, that
key, if it is presented to the Exokernel by
this library operating system, it's a valid key. Even
if it's a valid key, but it is not
the operating system to which Exokernel gave the key,
then that request would be denied. So with
a valid key, any time the library operating
system can present the key to the Exokernel,
Exokernel will validate it, and then, the library
operating system is free to go in using
that resource for which it has this valid
key. This is sort of like a doorman
in an apartment building, checking when a resident comes
in, whether the resident is a bona fide
occupant of the residence. Once inside his apartment,
what the resident does is not something that
the doorman cares about. Exactly the same thing
is being done by Exokernel as a doorman
for using the hardware resource for which a
valid key exists with a library operating system.
So, establishing the secure binding is a heavy
duty operation. That's where Exokernel comes in the middle of saying, well, this
particular library operating system wants access
to a specific resource, can I give
it? And it makes that decision. Once such a secure binding has been
established, the actual use of the hardware is going to be much cheaper.