Intra-unikernel isolation with Intel memory protection keys

Abstract

Unikernels are minimal, single-purpose virtual machines. This new operating system model promises numerous benefits within many application domains in terms of lightweightness, performance, and security. Although the isolation between unikernels is generally recognized as strong, there is no isolation within a unikernel itself. This is due to the use of a single, unprotected address space, a basic principle of unikernels that provide their lightweightness and performance benefits. In this paper, we propose a new design that brings memory isolation inside a unikernel instance while keeping a single address space. We leverage Intel's Memory Protection Key to do so without impacting the lightweightness and performance benefits of unikernels. We implement our isolation scheme within an existing unikernel written in Rust and use it to provide isolation between trusted and untrusted components: we isolate (1) safe kernel code from unsafe kernel code and (2) kernel code from user code. Evaluation shows that our system provides such isolation with very low performance overhead. Notably, the unikernel with our isolation exhibits only 0.6% slowdown on a set of macrobenchmarks.

Unikraft

“…• Single protection level: There should be no user-/kernel-space separation to avoid costly processor mode switches. This does not preclude compartmentalization (e.g., of micro-libraries), which can be achieved at reasonable cost [69]. • Static linking: Enable compiler features, e.g., Dead…”

FlexOS

“…More recently, OSes providing security through software isolation brought by safe languages [7,13,25,36,39] have been proposed. In SASOSes, isolation has been provided with traditional page tables [10,23,32] and recently through intra-address-space hardware isolation mechanisms [34,42,45,47]. Formal verification offers deterministic security guarantees, but has trouble scaling to modern OSes' large codebases [28,29].…”

“…Second, hardware isolation, SH and runtime property checking can be used to check that certain correctness properties hold (e.g. when specified as pre and post conditions), thus relieving the user from needing to prove code correctness statically against a specification [47]. Third, both software verification and protection domains can be used to ensure (a form of) control-flow integrity between components, guaranteeing that code execution starts only at well-defined entry points, without needing software runtime checks [53].…”

Towards a Hybrid Approach to Protect Against Memory Safety Vulnerabilities

“…Many other compartmentalization abstractions can be used for platforms that do not support hardware capabilities, relying on various isolation mechanisms. These can be process-based isolation leveraging page tables [36], [37]; VM-based isolation using hardware-assisted virtualization [38], [39]; trusted execution environments [40], [41] and other ISA extensions such as Intel MPK [42]- [45]; and finally software-only solutions such as SFI [46]. These techniques offer various security/performance trade-offs and generally require a particular porting effort to manage data shared between compartments.…”