Device Driver Safety Through a Reference Validation Mechanism Dan Williams Patrick Reynolds Kevin Walsh Emin Gu n Sirer Fred B Schneider Cornell University Abstract Device drivers typically execute in supervisor mode and thus must be fully trusted This paper describes how to move them out of the trusted computing base by running them without supervisor privileges and constraining their interactions with hardware devices An implementation of this approach in the Nexus operating system executes drivers in user space leveraging hardware isolation and checking their behavior against a safety specification These Nexus drivers have performance comparable to inkernel trusted drivers with a level of CPU overhead acceptable for most applications For example the monitored driver for an Intel e1000 Ethernet card has throughput comparable to a trusted driver for the same hardware under Linux And a monitored driver for the Intel i810 sound card provides continuous playback Drivers for a disk and a USB mouse have also been moved successfully to operate in user space with safety specifications 1 Introduction Device drivers constitute over half of the source code of many operating system kernels with a bug rate up to seven times higher than other kernel code 10 They are often written by outside developers and they are less rigorously examined and tested than the rest of the kernel code Yet device drivers are part of the trusted computing base TCB of every application because the monolithic architecture of mainstream operating systems forces device drivers to be executed inside the kernel with high privilege Some microkernels and other research operating systems 2 9 21 24 run device drivers in user space Supported by NICECAP cooperative agreement FA8750 072 0037 administered by AFRL AFOSR grant F49620 03 1 0156 National Science Foundation Grants 0430161 and CCF 0424422 TRUST ONR Grant N00014 01 1 0968 and Microsoft Corporation to isolate the operating system from accidental driver faults but these drivers retain sufficient I O privileges that they must still be trusted This paper introduces a practical mechanism for executing device drivers in user space and without privilege Specifically device drivers are isolated using hardware protection boundaries Each device driver is given access only to the minimum resources and operations necessary to support the devices it controls least privilege thereby shrinking the TCB 1 A system in which device drivers have minimal privileges is easier to audit and less susceptible to Trojans in third party device drivers Even in user space device drivers execute hardware I O operations and handle interrupts These operations can cause device behavior that compromises the integrity or availability of the kernel or other programs Therefore our driver architecture introduces a global trusted reference validation mechanism RVM 3 that mediates all interaction between device drivers and devices The RVM invokes a device specific reference monitor to validate interactions between a driver and its associated device thereby ensuring the driver conforms to a device safety specification DSS which defines allowed and by extension prohibited behaviors The DSS is expressed in a domain specific language and defines a state machine that accepts permissible transitions by a monitored device driver We provide a compiler to translate a DSS into a reference monitor that implements the state machine Every operation by the device driver is vetted by the reference monitor and operations that would cause an illegal transition are blocked The entire architecture is depicted in Figure 1 The RVM protects the integrity confidentiality and availability of the system by preventing Illegal reads and writes Drivers cannot read or modify memory they do not own User space Unprivileged Device drivers totype implementation demonstrates that this approach can defend against malicious drivers and that the performance costs of this enhanced security are not prohibitive 2 DSSes Compiler Kernel Interrupts Device I O Model RVM I O Trusted Reference Monitors Device Device Figure 1 Safe user space device driver architecture Priority escalation Drivers cannot escalate their scheduling priority Processor starvation Drivers cannot hold the CPU for more than a pre specified number of time slices Device specific attacks Drivers cannot exhaust device resources or cause physical damage to devices In addition given a suitable DSS an RVM can enforce site specific policies to govern how devices are used For example administrators at confidentiality sensitive organizations might wish to disallow the use of attached microphones or cameras or administrators of trusted networks might wish to disallow promiscuous sniffing mode on network cards One alternative to our approach for monitoring and constraining device driver behavior is to use hardware capable of blocking illegal operations Hardware based approaches however are necessarily limited to policies expressed in terms of hardware events and abstractions An IOMMU 1 4 14 23 for example can limit the ability of devices to perform DMA transfers to or from physical addresses the associated drivers cannot read or write directly IOMMUs however do not mediate aspects of driver and system safety that go beyond the memory access interface 7 for example an IOMMU cannot prevent interrupt livelock limit excessively long interrupt processing protect devices from physical harm by drivers or enforce site specific policies As IOMMUs become prevalent our approach could leverage them as hardware accelerators for memory protection In sum this paper shows how to augment common memory protection techniques with device specific reference monitors to execute drivers with limited privilege and in user space The requisite infrastructure is small easy to audit and shared across all devices Our pro Device drivers send commands to devices check device status using registers receive notification of status changes through interrupts and initiate bulk data transfers using direct memory access DMA How they do so constitutes a platform s I O model Our work is targeted to the x86 architecture and PCI buses what follows is a brief overview of the I O model on that platform Similar features are found on other processors and buses Modern buses implement device enumeration and endpoint identification Each device on a PCI bus is identified by a 16 bit vendor identifier and a 16 bit model number the