1. 1 Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines Joshua LeVasseur, Volkmar Uhlig, Jan Stoess, and Stefan G¨otz University of Karlsruhe, Germany Presented by Weining Gu and Long Wang Instructor: Sam King

2. 2 Motivation  Driver Subsystem contributes 60% of source code lines in Linux Kernel 2.4.20  Device drivers contain more errors compared to other subsystems  Drivers can potentially propagate faults to other subsystems, leading to sporadic system crashes / hangs Full reuse and strong isolation of legacy device drivers  Virtual Machine

3. 3 Approach  Wrap device drivers in virtual machines  Use of a device driver is translated into a client-server transaction

4. 4 Hypervisor (L4 Microkernel) Application Client Virtual Machine 1 (Linux 2.6.8.1) Client Virtual Machine 2 (Linux 2.6.8.1) DD Virtual Machine 1 (Linux 2.4.22) DD Virtual Machine 2 (Linux 2.4.22) Architecture VMM (User level L4 task) File system Process Management Memory Management Scheduling Application File system Process Management Memory Management Scheduling OS Services PCI Driver NET Driver OS Services Optical Media Disk Driver (Interrupt) (Response as a trap) Translation Modules Guest OS Interrupt I/O I/O Request

5. 5 Components Hypervisor –in privileged mode –multiplexes processor between VMs –enforces protection for memory and I/O VMM –either in privileged or unprivileged mode –Implements the virtualization E.g. translating access faults into device emulators Device driver OS (DD/OS) –Performs I/O operations (through either port I/O or memory mapped I/O) –I/O operations restricted to those devices managed by the DD/OS Client –An entity that uses device services –An application process, a system process/operation, a DD/OS for another client, or the hypervisor itself Translation module –An extension of the DD/OS’s kernel for interfacing and mapping the client-to- DD/OS communication

6. 6 Driver Reuse and Isolation

7. 7 A case study

8. 8 Dependability Enhancing  System Reliability  Driver isolation by preventing fault propagation between erroneous driver, correct driver, and client OS  System Availability  Driver restart by rebooting the DD/OS virtual machine upon a driver failure  Proactive driver restart to remove latent errors or upgrade drivers  Driver restart occurs in mode of Asynchronous: failure identification, malicious driver Synchronous: live upgrade, proactive restart  Driver grouping  Groups drivers within the same DD/OS  Tradeoff between dependability and performance  Possible grouping methods Related drivers Drivers with similar stability/reliability

9. 9 Design Issues  DMA operations  Drivers may execute DMA operations  DMA operates on physical address of the host machine Needs to be mapped to physical address of the virtual machine Otherwise, a malicious driver overwrite/replace code or data of other VMs (guest OSes and applications)  Shared code/data of the hypervisor, VMM can be overwritten/replaced  A DD/OS is more than driver groups  Consumes more resources (CPU, memory, address space, etc)  Requires some events/operations for normal behavior Interrupt handling, message communication  Timing  Some applications or drivers require special timing

10. 10 Direct Memory Access (DMA) Device driver (Courtesy to Jonathan Walpole)

11. 11 DMA Address Translation  Problem: DMA in DD/OS VM operates on physical address of the host machine instead of physical address of the VM  Solution:  DMA operations are intercepted by the VMM through memory protection hardware When hardware support is unavailable, device drivers should be part of Trusted Computing Base (TCB)  DMA addresses are translated to indicate the correct physical addresses Address remapping with DMA address translation functions Memory balloon without DMA address translation functions

12. 12 DMA and Trust  Problem: Shared data/code of hypervisor and VMM between VMs can be overwritten by DMA drivers  Solution:  For untrusted clients only: DMA-involved memory are shared between clients and DD/OSs The memory are statically allocated or pinned  For untrusted clients and DD/OSs, besides the measures above: DD/OSs must be granted permission by hypervisor to access of client memory The hypervisor also restricts the amount of client memory used by the DD/OS  For cases when clients and DD/OSs distrust each othe, besides the measures above: Client pins its own memory DD/OS validates pinning of the client memory with the hypervisor

13. 13 IO-MMU  IO-MMU has been present on major HW architectures since the paper was published  Current IO-MMU  assigns each device a protection domain  allows VMM to set up I/O page tables to map host physical address to guest physical address  supports I/O virtualization in hardware

14. 14 Resource Consumption  Problem:  A DD/OS consumes an amount of memory  A DD/OS has processing overhead Timing, housekeeping (page aging, cleaning, periodical tasks)  Solution:  Page sharing Kernel image (for same DD/OSs), steady states  Page swapping In all DD/OSs except the swap DD/OS (because unused pages are identified by the swap DD/OS)  Memory ballooning  virtual zero pages  Compression for inactive pages  Release of requirements on some housekeeping if acceptable E.g. clock drift is acceptable if time on the DD/OS is not important

15. 15 Timing  Problem:  A virtual time is a slowdown version of the real time  Real-time hardware devices malfunction when timing assumptions are violated  Solution:  Avoid preemption within time-critical tasks Disable preemption during the tasks, e.g. disable hardware interrupt Preemption initiated during the tasks is postponed until preemption is enabled  After a maximum period, preemption is forcefully enabled In order to avoid potential DoS attack by malicious VMs

16. 16 Prototype Implementation  Uses a paravirtualization environment (L4 microkernel system)  Studies two systems  baseline system: Linux  device driver reuse system: client and DD/OS systems in Linux Kernel modules installed on both client and DD/OS systems  Uses three drivers in experiments  Network, disk, PCI

17. 17 Discussion (1) (collected from web board) Driver virtualization –How to control devices’ (like DMA) direct use of physical address (for non- malicious device)? designs simple logic in controlling device behavior (e.g. a simple state machine) in VMM Xen’s “I/O spaces” to provide shared access to device drivers Binary translation of device drivers can be used for enforcing access restrictions Any other devices using physical address directly? –Hardware support for driver(or I/O) virtualization Assigns each device an address domain in guest OS (AMD IOMMU) Protection of memory from DMA in hardware (Intel’s new LaGrande architecture) Other support? –Multiplexing of hardware device service for multiple VMs Xen is able to split access to the PCI bus among VMs Use transaction-similar conception, or disable interrupting the device during a device operation? Can every device be multiplexed among VMs inherently? Feasibility/scalability with respect to overhead –For a large number of drivers –For time-sensitive drivers, e.g. video/audio adaptor, game controller, VOD system

18. 18 Discussion (2) Correctness preservation after the proposed approach is applied –Will race conditions be brought by applying the client/server scenario? Especially when multiplexing multiple VMs, driver reuse and consolidation are concerned? –How to prove the correctness of system behavior is still preserved with measures and heuristics applied? E.g. timing issue, page sharing/compression/swapping Driver virtualization/isolation vs Microkernel approach –What is the similarity and difference between these two? Miscellaneous issues –Can this approach be used to solve the problem of lack of drivers on Linux? (drivers on Windows are usually provided by vendors)