OP2: Building hardware that exposes an exokernel interface

Tudor David
 
The main principle the exokernel advocates is that hardware capabilities should not be limited in the kernel by providing fixed ways to use them. When considering the placement of an exokernel in hardware, one must be careful not to make the same mistake, that of limiting the way software can use hardware. If hardware support were to be offered for exokernel, one should still be able to turn it off and use some other operating system type. More interesting is the problem of whether an entire exokernel should be provided by the hardware or only some parts of it.

The essence of an exokernel is that applications are given direct access to physical resources, provided they have the required rights. In order to ensure this, the operations the exokernel exports are encapsulated within calls which check the ownership of the resources being used. The exokernel is involved in managing these permissions, allocating them by creating secure bindings and removing them through revocation and abort protocols. This is common to all exokernel implementations. Moreover, these protection and hardware access mechanisms are closely linked to the hardware, depending more on the machine rather than on the software. However, an exokernel also implements a number of system calls which are less linked to the hardware and are specific to particular exokernel implementations, such as dispatching exceptions or creating abstractions (e.g. time slices) and calls that might aid in scheduling.

In my opinion, moving the protection and hardware access calls to BIOS might indeed be a good thing (device access mechanisms are provided in today’s BIOSes as well.). It would make the interfaces to the hardware independent of the exokernel implementation being deployed. Otherwise, exokernels might have differences in their interfaces and require more effort to move libOSes and applications from one exokernel to another. It would also reduce the amount of functionality a particular exokernel would need to implement, by providing some of it from hardware. Moreover, in an exokernel model, it would not take away any of the power the hardware offers and would not restrict the software’s flexibility in any way.

But should the mechanisms and abstractions specific to particular exokernel implementations also be provided by the hardware? My opinion is they should not. By adding them to the hardware, we would essentially be imposing some restrictions on the software, which is exactly what the exokernel model was trying to prevent. Software should not be forced by the hardware to use the time slices abstraction for example. Moreover, these mechanisms seem less coupled to the hardware, but rather build upon it, and therefore belong to the software layer above it in my opinion. If these were deployed in software, one could easily replace an exokernel implementation (e.g. Aegis) with another, thus allowing greater flexibility.

To conclude, I would say that offering a hardware interface which would ensure protected resource access could indeed be useful, but this does not extend to the entire exokernel implementation.