Unik ikernel ernels: s: Li Libr brar ary O y Oper erating ng - PowerPoint PPT Presentation

Unik ikernel ernels: s: Li Libr brar ary O y Oper erating ng Sy Systems ems f for t or the he Cl Clou oud Ani nil Mad adha havap apeddy, Richa chard Mortier, Cha haralam ampos Rotsos, Davi avid Scott, Bal Balraj Sing ngh, h, Tho homas Gaz azagnai naire, Steve ven n Smith, h, Steve ven n Ha Hand nd and and Jon n Cr Crowcr crofu fu ASPLOS OS’13 In The Context of the CS3551 Spire Class Project Brad Whitehead and Mike Boby February 25, 2020

Teac aching ng M Mom oment nt - - Wha What is is a U a Unik ikerne nel?  To answer that question, we have to t ake a look at the structure of a modern operating system  Doesn’t matter if it’s Microsoft Windows, Linux, UNIX, Mac OS X OS X macOS, etc.  All the mainstream operating systems have the same fundamental anatomy

The The Ana Anatomy my of of an Ope an Operatin ing S Sys ystem “The Kernel”  Runs in Special Hardware Mode “Userland”  – “Ring 0”  Where Applications  Only Program That Can Run Access or Allocate Resources  No Privileges  Copies Data Between  Can Not Access Programs Resources   Can Not “Talk” to Other Programs

Growth th o of O f Ope peratin ting S Systems s  Linux Kernel is now 28 million lines of source code!  Windows is estimated at 50 million lines of code!!  With an industry average of 15-50 defects per 1000 lines of code*:  Linux (Just the kernel) = 420 thousand to 1.4 million defects  Windows = 750 thousand to 2.5 million defects  * Steve McConnel, “Code Complete 2”, 2005

It G t Gets W s Wors rse  The “Userland” support sofuware is ofuen 10 to 20 times larger than the kernel  Red Hat Enterprise Linux (RHEL) Userland is approximately 420 million lines of code  Try not to think about the 6.7 to 22 million defects running on the SCADA server controlling your power grid and drinking water

Can I It t Get E t Eve ven W n Wors rse?  The Linux kernel is full of junk!  A large number of device drivers are routinely compiled into the kernel, regardless of the actual hardware in the computer  There are device drivers for hardware that no longer exists  Silicon Graphics video drivers were just added to the Linux 5.5 kernel!  Amazon AMI images have had drivers for floppy disks and audio cards!  In 2015, the Venom vulnerability (CVE-2015-3456) used a flaw in the floppy disk controller (FDC) driver to compromise both physical and virtual machines

And I d It Do Doesn sn’t E ’t End nd Th There  Likewise, there are thousands of storage and communications protocols in the kernel that will not be used in your application  Linux recognizes 7 difgerent executable formats, even though the vast majority of applications (including Spire) are in ELF format  Each of these extra, unused chunks of code (with its 15-50 defects/1000 SLOC) is a potential entry point for compromise

Wha What If We If We C Cut Ou t Out the P e Part arts We We Do Don’t N t Need? d?  Code traces show that the average application uses less than 0.08% of the total code in the kernel  Take the standard C library as an example  The C library contains thousands of functions, but a modern linker only includes the actual functions (and code) that an application uses  Could we do the same with our operating system?

We Ca e Can Cr Create A e A L Lib ibrary of Op of Operatin ing Sy g System m Function tions  Common operating system functions, drivers, and protocols are written as a library of functions  When you link these “library operating system” functions to your application, you have a single executable that runs directly on hardware or a hypervisor as a stand-alone virtual machine (VM)…  Only the functions, drivers, and protocols actually used in the application are linked into the executable/VM …You have a Unikernel!

So Wh o What Do Does s a U a Unik ikerne nel L Look Lik Like? Unikernel Compiler “Ring 3” “Ring 0” “Ring 0” OS Functjons

Unikerne rnel A l Appr proach ches  “From the Ground Up” - Programmer writes code specifically for the Unikernel library functions  Mirage  “Partition an Existing Kernel” - Extract all the functions of an existing kernel and include only needed functions during compile  Rump kernel  “POSIX/Linux Interface to New Library Functions” - New, modernized functions are written for the library, but clients call the functions through existing interfaces  IncludeOS

The P Paper’s s Focu cus  Mirage  A set of libraries that perform the functions commonly associated with the operating system for memory management, execution, and communications  Written in a strongly typed functional language, OCaml  OCaml applications linked with the Mirage libraries form virtual machine images (unikernels) designed to be run on the Xen hypervisor  Mirage unikernels use Xen for device drivers and scheduling

The P Paper r - - Why Unik ikerne nels ls?  Enhanced Security  Hardware-Enforced Access Controls  Less Code  Immutable  No System Calls  Per-Compile Randomization  Single Address Space  No Expensive Context Switches  Zero Copy  Small Executable Size  Reduced Runtime Complexity (No Scheduler)

Arch chit itectu ture o of a a Unik Unikern rnel (1 l (1/3 /3)  Configuration and Deployment  Instead of /etc and config files, the application configuration is defined at compile time and compiled directly into the executable code.  Configurations are explicit and manipulated directly by the high level language making them subject to type checking and static anaysis  Reduced efgort to configure multi-service applications  Compactness and Optimization  Using only the required functions makes for compact code  Since the compiler sees all the code, it can apply optimizations to the entire unikernel

Arch chit itectu ture o of a a Unik Unikern rnel (2 l (2/3 /3)  Threat Model  Tenants in a shared cloud environment (possibly Spire data center controllers)  Across the network (definitely Spire)  Hypervisor provides isolation and access control  Compile time specialization (no system calls, no scheduler, etc.)  Single Image  Removal of all unused functions and code  Pervasive Type Safety  Mirage uses a single, strongly typed language

Arch chit itectu ture o of a a Unik Unikern rnel (3 l (3/3 /3)  Sealing and Privilege Dropping  Mark code as immutable, enforced by hypervisor  Code pages are marked “read-only”  Data pages (stack, heap, mmap, etc.) are marked “non-executable”  Harvard architecture instead of Von Neumann architecture  Compile-Time Address Space Randomization  Mirage unikernel toolchain can produce randomized internal addresses (equivalent to ASLR)

Co Compone mponent nts s of of t the he Mir Mirag age Unik Unikerne rnel (1 l (1/4) /4)  OCaml  The majority of the operating system functions are written from scratch in OCaml, a strongly typed functional language  The authors attribute much of Mirage’s reliability to the use of OCaml  PVBoot Library  Minimal code required to:  Create a single 64 bit address space  Load unikernel image  Allocate required memory to unikernel data structures  Use 1 vCPU  Connect to Xen event channels  Compiled directly into the unikernel image

Co Compone mponent nts s of of t the he Mir Mirag age Unik Unikerne rnel (2 l (2/4) /4)  Language Runtime  Mirage uses a specialized OCaml runtime library  Modified for single address space layout  Memory mapped I/O between Mirage unikernel VMs on the same Xen hypervisor  PVBoot provides a single event-driven execution loop  Thread concurrency comes from a Lightweight Thread Library written in OCaml  Device Drivers  Mirage uses Xen device drivers  Xen device drivers communicate with VMs using a single shared memory page of “slots” arranged in a ring bufger, with event channels for signaling  Mirage wraps this Xen ring I/O within OCaml functions for type safety enforcement

Co Compone mponent nts s of of t the he Mir Mirag age Unik Unikerne rnel (3 l (3/4) /4)  Zero-Copy Device I/O  With a single address space, no need to copy data from kernel space to user space  Type-Safety Protocol I/O  All I/O is wrapped in OCaml for type safety, eliminating bufger overflow errors/attacks

Co Compone mponent nts s of of t the he Mir Mirag age Unik Unikerne rnel (4 l (4/4) /4)  Network Processing  Fast shared memory between unikernels in the same hypervisor  “Scatter/Gather” approach to build and send Ethernet TCP/IP I/O  Storage  Uses “shared page” I/O ring bufger with Xen hypervisor for block storage  OCaml library in unikernel provides filesystem abstraction over the blocks

Evalu luatio tion (1 n (1/3 /3)  Microbenchmarks  Boot Time  Mirage boots in 50 milliseconds, versus 500 milliseconds for an equivalent Linux VM  Threading  Mirage can launch 20 million threads per second, versus 4 seconds for an equivalent Linux VM  Networking and Storage  Mirage was 4-10% slower than Linux VM when processing ICMP Ping requests  Mirage was slightly faster than Linux on IPv4 reads (zero-copy) and slightly slower on writes because of CPU operations in protocol libraries  Mirage and Linux direct I/O storage throughput efgectively the same (1.6 GB/sec)