During the design and implementation of the Nested Kernel and PerspicuOS we learned several important lessons about implementation specific issues as well as the relation between the various artifacts and prior work. In this section we detail key lessons and takeaways.
8.1.1
Virtualizing Supervisor Privilege with the WP-bit
PerspicuOS demonstrates a new technique that alleviates the need for higher layers of hardware privilege to gain separation even on supervisor privileged code: restricting access to both CPU and memory state by using simple MMU configuration combined with easy to verify static code properties. This technique impacts both the portability and performance of the resulting solution. Early hierarchical operating system designs (e.g., Multics (Organick, 1972)) had multiple privilege levels; however, due to common hardware platforms only having two privilege levels (e.g., Compaq Alpha and Silicon Graphics MIPS), user and supervisor, operating system designers built their operating systems without any internal separation because the operating system would not be easily portable (Russinovich et al., 2012). In PerspicuOS, virtualizing the single privilege level
provides a tremendous benefit in portability in the Nested Kernel design and path to adoption, specially given that the layer of functionality is so minimal: only the MMU.
We believe that the technique introduced by PerspicuOS is unique in that it presents a solution that uses only the MMU combined with simple to verify binary code properties to gain isolation: presenting a mechanism that can be employed in gaining a layer of isolation for future systems. Additionally, using the WP-bit eliminates the need to flush the address translation cache on each invocation to the nested kernel, and therefore is more efficient than conventional boundary crossings. Finally, single privilege layer virtualization also has implications for applying similar techniques to VMMs such as Xen where no higher privilege layer exists: a key direction of future work.
8.1.2
Operating System Organizations
The Nested Kernel Architecture is one instance of what early operating system researchers called the “nucleus” of the system: a core component that provides the most primitive functionality and abstractions to service the larger operating system. The microkernel operating system design is one instance of such a nucleus and at first glance the Nested Kernel could be consider similarly; however, we argue that the Nested Kernel is an alternative of the same nucleus idea, which is distinct from the microkernel. The primary distinction between the Nested Kernel and a typical microkernel is that the nested kernel demonstrates an isolation layer of only the MMU, in contrast to a typical microkernel that provides address spaces, scheduling, and message passing.
Another key distinction that is a result of the Nested Kernel overall approach of retrofitting into monolithic kernels is that microkernels were originally designed as a service and abstraction layer for other operating systems, however, it was developed without any particular operating system in mind. In other words, at their invention microkernels were designed to support a wide variety of potential operating systems, which may be why they are larger than the Nested Kernel. In contrast the Nested Kernel is similarly a primitive nucleus but with a very specific type of operating system in mind: monolithic operating system. Because of this the Nested Kernel can be tailored much more specifically to the abstractions needed to seamlessly, or with minimal effort, integrate into monolithic operating system, while keeping the domains as minimal as possible, such as the case with our design choices of only encapsulating the last step of MMU modification in PerspicuOS. This has the added benefit of leveraging all the stability of a code base with such longevity of implementation and reliability as Mac OS X, Windows, and Linux while moving towards an overall architecture with strong resiliency through decomposition. As described by the ongoing work to extend the basic Nested Kernel services already published, the Nested Kernel and following work will develop and integrate a kernelized design into existing commodity monolithic operating systems.
8.1.3
Performance Sensitivity
Adding layers of security to any code base is going to result in performance degradation, which if unchecked would lead to an impractical option for commodity systems. As our experiments showed, if we had decided to utilize hardware virtualization extensions, the per nested kernel invocation costs would be 3.7 times worse than using the WP-bit . Therefore, the use of the WP-bit and single privilege level separation not only provides a new virtualization technique but also an efficiently performing choice.
8.1.4
Nesting in the Linear Address Space
One of the biggest challenges of decomposing an existing code base is the cost in terms of code modifications. And thus one of the fundamental design decisions was to maintain as much as pos- sible the linear address space, and nest the higher privilege state within the traditional monolithic address-space: in standard operating system parlance, separating addressing from protection. The result is that code outside the nested kernel can still read the protected state without any modifi- cations to memory layout or calls into supervisor code, and only requires entrance into the nested kernel on writes to PTPs, which is a minimal subset of the operating system in the first place. Of course when adding confidentiality these properties may seem less viable, however, when employing confidentiality the kernel designer wants to minimize access, employing least privilege, and therefore external access should be minimal.
8.1.5
The Protection Granularity Gap
A common problem known as the protection granularity gap (Wang et al., 2009) presents itself in the Nested Kernel Architecture write-protection interface. The problem is that memory protections could be defined for only a subset of an entire page of memory; thus, all writes to non-write protected memory on that page will trap. To handle this the Nested Kernel Architecture suggests incorporating a memory allocation scheme that bundles write protected objects into pages set aside for write protection purposes, thereby, avoiding costly trap and emulate to update mixed data pages. Chapter 6 presented such an allocation scheme for both statically and dynamically allocated objects, including examples of its use.
8.1.6
Bridging the Semantic Gap
A common security solution is to use higher privilege components, typically referred to as a secu- rity monitor, to enforce secure properties on the monolithic operating system. Examples include code integrity or trust measurements of signed applications (Payne et al., 2008; Sharif et al., 2009; Seshadri et al., 2007), however, existing solutions typically use VMM isolation, which beyond per- formance has issues of the semantic gap, namely that the data structures in the kernel are not
known to the hypervisor. The co-design technique that we employ in the Nested Kernel allows full semantic knowledge of all operating system internal objects and therefore no semantic gap problem. The reason why Nested Kernel conquers this problem is not due to the single privilege level, but rather due to the co-design of the security monitor with the operating system kernel itself.