Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines Joshua LeVasseur Volkmar Uhlig Jan Stoess Stefan Gotz¨ University of Karlsruhe, Germany Abstract hardware. The likelihood of programming errors in com- We propose a method to reuse unmodified device monly used device drivers is probably much lower than drivers and to improve system dependability using vir- in application code; however, such errors are often fa- tual machines. We run the unmodified device driver, with tal. Device drivers, traditionally executing in privileged its original operating system, in a virtual machine. This mode, can potentially propagate faults to other parts of approach enables extensive reuse of existing and unmod- the operating system, leading to sporadic system crashes. ified drivers, independent of the OS or device vendor, In this paper we propose a pragmatic approach for significantly reducing the barrier to building new OS en- full reuse and strong isolation of legacy device drivers. deavors. By allowing distinct device drivers to reside in Instead of integrating device driver code we leave all separate virtual machines, this technique isolates faults drivers in their original and fully compatible execution caused by defective or malicious drivers, thus improving environment—the original operating system. We run the a system’s dependability. device driver wrapped in the original operating system in We show that our technique requires minimal support a dedicated virtual machine (VM). Thus we can (almost) infrastructure and provides strong fault isolation. Our guarantee that semantics are preserved and that incom- prototype’s network performance is within 3–8% of a patibilities are limited to timing behavior introduced by native Linux system. Each additional virtual machine in- virtual machine multiplexing. creases the CPU utilization by about 0.12%. We have The virtual machine environment also strongly iso- successfully reused a wide variety of unmodified Linux lates device drivers from the rest of the system to achieve network, disk, and PCI device drivers. fault containment. The isolation granularity depends on the number of collocated drivers in a single VM. By in- stantiating multiple collaborating VMs we can efficiently 1 Introduction isolate device drivers with minimal resource overhead. Reuse of device drivers and driver isolation are two The majority of today’s operating system code base is important aspects of operating systems; however, they 1 accounted for by device drivers. This has two major are usually discussed independently. With virtual ma- implications. First, any OS project that aims for even a chines, we propose to use a single abstraction to solve reasonable breadth of device drivers faces either a major both problems in an extremely flexible, elegant, and effi- development and testing effort or has to support and inte- cient way. grate device drivers from a driver-rich OS (e.g., Linux or Windows). Even though almost all research OS projects reuse device drivers to a certain extent, full reuse for 2 Related Work a significant driver base has remained an elusive goal and so far can be considered unachieved. The availabil- Our work uses known principles of hardware-based iso- ity of drivers solely in binary format from the Windows lation to achieve driver reuse and improved system de- driver base shows the limitations of integration and wrap- pendability. It is unique in the manner and the extent to ping approaches as advocated by the OS-Kit project [10]. which it accomplishes unmodified driver reuse, and how Also, implicit, undocumented, or in the worst case incor- it improves system dependability, in terms of drivers, rectly documented OS behavior makes driver reuse with without system modification. a fully emulated execution environment questionable. The second implication of the large fraction of driver 2.1 Reuse code in mature OS’s is the extent of programming er- rors [7]. This is particularly problematic since testing Binary driver reuse has been achieved with cohosting, requires accessibility to sometimes exotic or outdated as used in VMware Workstation [32]. Cohosting mul- tiplexes the processor between two collaborating oper- 1Linux 2.4.1 drivers cover 70% of its IA32 code base [7]. ating systems, e.g., the driver OS and the VM monitor. USENIX Association OSDI ’04: 6th Symposium on Operating Systems Design and Implementation 17 When device activity is necessary, processor control is Sharing Conflicts transfered to the driver OS in a world switch (which re- A transplanted driver shares the address space and privi- stores the interrupt handlers of the driver OS, etc.). The lege domain with the new OS. Their independently de- driver OS releases ownership of the processor upon de- veloped structures contend for the same resources in vice activity completion. The cohosting method offers no these two domains, and are subject to each other’s faults. trust guarantees; both operating systems run fully priv- Due to picky device drivers and non-modular code, ileged in supervisor mode and can interfere with each a solution for fair address space sharing may be un- other. achievable. The older Linux device drivers, dedicated to Device drivers are commonly reused by transplant- the IA32 platform, assumed virtual memory was idem- ing source modules from a donor OS into the new OS potently mapped to physical memory. Reuse of these [2, 4, 11, 15, 28, 35]. In contrast to cohosting, the new drivers requires modifications to the drivers or loss in OS dominates the transplanted drivers. The transplant flexibility of the address space layout. The authors in merges two independently developed code bases, glued [28] decided not to support such device drivers, because together with support infrastructure. Ideally the two sub- the costs conflicted with their goals. The authors of [15] systems enjoy independence, such that the design of one opted to support the drivers by remapping their OS. does not interfere with the design of the other. Past work Privileged operations generally have global side ef- demonstrates that, despite great effort, conflicts are un- fects. When a device driver executes a privileged opera- avoidable and lead to compromises in the structure of the tion for the purposes of its local module, it likely affects new OS. Transplantation has several categories of reuse the entire system. A device driver that disables processor issues, which we further describe. interrupts disables them for all devices. Cooperatively designed components plan for the problem; driver reuse Semantic Resource Conflicts spoils cooperative design. The transplanted driver obtains resources (memory, locks, CPU, etc.) from its new OS, subject to normal Engineering Effort obligations and limitations, creating a new and risky re- Device driver reuse reduces engineering effort in OS lationship between the two components. In the reused construction by avoiding reimplementation of the de- driver’s raw state, its manner of resource use could vi- vice drivers. Preserving confidence in the correctness of olate the resource’s constraints. The misuse can cause the original drivers is also important. When given de- accidental denial of service (e.g., the reused driver’s non- vice drivers that are already considered to be reliable and preemptible interrupt handler consumes enough CPU to correct (error counts tend to reduce over time [7]), it is reduce the response latency for other subsystems), can hoped that their reuse will carry along the same proper- cause corruption of a manager’s state machine (e.g., in- ties. Confidence in the new system follows from thor- voking a non-reentrant memory allocator at interrupt ough knowledge of the principles behind the system’s time [15]), or can dead-lock in a multiprocessor system. construction, accompanied by testing. These semantic conflicts are due to the nature of OS Reusing device drivers through transplantation re- design. A traditional OS divides bulk platform resources duces the overall engineering effort for constructing a such as memory, processor time, and interrupts between new OS, but it still involves substantial work. In [10] an assortment of subsystems. The OS refines the bulk re- Ford et al. report 12% of the OS-Kit code as glue code. sources into linked lists, timers, hash tables, top-halves Engineering effort is necessary to extract the reused and bottom-halves, and other units acceptable for dis- device drivers from their source operating systems, and tributing and multiplexing between the subsystems. The to compile and link with the new operating system. The resource refinements impose rules on the use of the re- transplant requires glue layers to handle semantic differ- sources, and depend on cooperation in maintaining the ences and interface translation. integrity of the state machines. Modules of independent For implementation of a glue layer that gives us con- origin substitute a glue layer for the cooperative design. fidence in its reliability, intimate knowledge is required For example, when a Linux driver waits for I/O, it re- about the functionality, interfaces, and semantics of the moves the current thread from the run queue. To capture reused device drivers. The authors in [2, 15, 28] all the intended thread operation and to map it into an opera- demonstrate intimate knowledge of their source operat- tion appropriate for the new OS, the glue layer allocates a ing systems. Linux thread control block when entering a reused Linux The problems of semantic and resource conflicts mul- component [2,28]. In systems that use asynchronous I/O, tiply as device drivers from several source operating sys- the glue layer converts the thread operations into I/O con- tems are transplanted into the new OS. Intimate knowl- tinuation objects [15]. edge of the internals of each source operating system 18 OSDI ’04: 6th Symposium on Operating Systems Design and Implementation USENIX Association is indispensable. Driver update tracking can necessitate drivers. On the other hand, applications in the same en- adaptation effort as well.