1. DriverGuard: A Fine-grained Protection On I/O Flows Yueqiang Cheng, Xuhua Ding and Robert H. Deng School of Information Systems Singapore Management University The 16 th European Symposium on Research in Computer Security (ESORICS), 12-14 Sep 2011, Leuven (Belgium)

2. 2 Background and Motivations I/O flow protection is important and urgent – Sensitive information in I/O flows Biometric information (e.g., fingerprint template) Password and credit card number Sensitive document printing – Device drivers lack of security functions More loopholes due to the higher bug rate (compared to other kernel code) ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows2

3. 3 Typical I/O Flow ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows3 Data regions  I/O ports or MMIO  Driver buffers  kernel stacks  User-space regions So many possible target interfaces and regions for attackers Device I/O Interfaces  I/O ports  Memory-Mapped IO (MMIO)  DMA

4. 4 No Good Existing Solutions ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows4 deviceDriverApplication Remote server Unprotected Terra/Overshadow Data Flows in Alice’s Computer TLS/SSL Our goal: a generic solution to dynamically safeguard I/O flows from devices to applications The data in I/O flows from devices to applications are unprotected

5. 5 Challenges Complex I/O subsystems – Different I/O interfaces – Complex interactions among drivers and kernels Powerful attacks – kernel rootkits have the same (highest) privilege as the kernel to access any memory region Directly access data regions Device I/O control manipulation ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows5

6. 6 Threat Model I/O requests from user space are well- protected Trusted hardware and System Management Mode (SMM) Trusted hypervisor (or VMM) – Trusted booting guarantees load time integrity – IOMMU prevents malicious DMA transactions Devices drivers are benign drivers The guest kernel is malicious – The purpose of the malicious guest kernel is to steal sensitive information ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows6

7. 7 Design Alternatives Location Isolation – putting drivers into driver domain or the hypervisor space – Large TCB decreases the security level of the whole platform Execution Isolation – securing the driver’s execution in untrusted kernel space – Hard to isolate due to intensive driver-kernel interactions – I/O subsystems which needs to be enclosed in execution isolation dramatically increases the size of TCB ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows7

8. 8 Features of Drivers Most of the driver code is for housekeeping purposes (e.g., error handling, resource allocation and cleaning up) Only a small portion of driver code dealing with I/O data transferring, and in these code – Only a few code blocks (e.g., decoding) need to know the content to process the I/O data, or to issue command to devices ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows8

9. 9 Features of Drivers (cont.) DriverGuard distinguishes code blocks, which issue commands or need to know the content of data, from other driver code ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows9 ehci_irq -> ehci_writel -> ehci_work -> … (several internal functions) -> uvc_video_complete -> uvc_video_decode_isoc -> … Issue command Some of code blocks need to know the content of data to do decode operations USB-Camera Driver

10. 10 DriverGuard Architecture DriverGuard works in the hypervisor space DriverGuard manages access permissions of device I/O interfaces and memory regions DriverGuard can intercept guest interrupts and exceptions ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows10 Hypervisor with DriverGuard Device Driver Application Guest Kernel User Space

11. 11 Our Approach in DriverGuard ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows11 Only code segments that need to access the I/O data or issue I/O commands: Have the privilege to access the data and/or device I/O interfaces Executions are safeguarded by the hypervisor Enforce access control - Set Device I/O interfaces inaccessible The data in data regions is encrypted

12. 12 Privileged Code Block (PCB) We call the high privilege code blocks in a driver as Privileged Code Blocks (PCB) – Command-PCB: issue I/O commands – Computation-PCB: make computation on I/O data – Key-PCB: for cryptographic operations. ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows12 Command-PCB and Computation-PCB are original driver code; key-PCBs are introduced as library functions called by drivers.

13. 13 Key-PCB – Generate the driver's encryption key – Each driver has its own dedicated key-buffer in the guest domain. – The key is used by computation-PCBs DriverGuard enforces access control on the key buffer. ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows13

14. 14 Privileged Code Block (cont.) A driver’s PCBs are manually identified. Requirements on PCB – Stateless code No extra data dependence – Self-contained code No extra code dependence. Do not call non-PCBs. – No indirect call or indirect jump (e.g., no call using function pointer) ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows14

15. 15 Access control enforcement - DriverGuard sets device I/O interfaces and updated data regions inaccessible IOPL and I/O bitmap for I/O ports access control Page Table Entry (PTE) for memory access control Example with Typical Input Flow Initialization step – Context initialization DriverGuard collects locations of PCBs PCBs issue hypercalls to update – Devices I/O interfaces – Data regions ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows15 Hypervisor with DriverGuard Device Driver with PCBs … Guest Kernel Application User Space

16. 16 1. Driver gets read request from user space ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows16 Example with Typical Input Flow (cont.) Hypervisor with DriverGuard Device Driver with PCBs … Application User Space DMA buffer Driver buffer Data buffer Guest Kernel Request a)A PCB issues hypercall to ask DriverGuard protecting DMA buffer b)A PCB issues command(s) to device I.Update address of DMA buffer to device

17. 17 Example with Typical Input Flow (cont.) 2. Device uses DMA to transfer data into DMA buffer, and generates an interrupt ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows17 Hypervisor with DriverGuard Device Driver with PCBs … Application User Space DMA buffer Driver buffer Data buffer Guest Kernel 3.Getting the interrupt, a PCB accesses the Input (raw) data DMA buffer Plain text Driver Execution Flow In PCB execution Access grantEncrypting Plain text Cipher text

18. 18 Example with Typical Input Flow (cont.) 4. A PCB may do computation operations on data ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows18 Hypervisor with DriverGuard Device Driver with PCBs … Application User Space DMA buffer Driver buffer Data buffer DMA buffer Plain text Driver Execution Flow In PCB execution DecryptingEncrypting Cipher text Guest Kernel

19. 19 5. Data movement Do not need to know the content of data Not need PCBs ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows19 Example with Typical Input Flow (cont.) Hypervisor with DriverGuard Device Driver with PCBs … Application User Space Data buffer 6.Finally data is transferred into user space The data is decrypted DMA bufferDriver bufferData buffer Driver buffer Guest Kernel

20. 20 PCB Execution Escorting ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows20 If the PCB is scheduled off CPU  DriverGuard sets the data region(s) inaccessible  DriverGuard prepares a fake kernel stack to prevent attackers getting sensitive information from stack Cipher text Plain text Cipher text Off CPUOn CPU Driver Execution Flow In PCB execution Out of PCB execution DecryptingAccess DeniedAccess GrantEncrypting If the PCB is scheduled on CPU  DriverGuard sets the data region(s) accessible.  DriverGuard restores the original kernel stack

21. 21 Implementation The prototype of DriverGuard is built based on Xen 4.0 – Only add less 2k SLOC in Xen The total PCB code only account for 1% of the driver code (with Linux 2.6.31) ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows21

22. 22 Evaluation We test the security of DriverGuard with several public rootkits (e.g., keyloggers) We test the performance overhead with five device drivers: keyboard, camera, fingerprint reader, printer, sound card ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows22 Keyboard input transfer Camera waiting Fingerprint collection 1 page print Sound card open Without DriverGuard 0.053ms33.24ms2.61s15.74s7.8 μs With DriverGuard0.138ms33.38ms2.63s16.19s12.3μs Percentage160.40%0.42%0.77%2.86%57.7%

23. 23 Limitations The main drawback of our scheme is the need for manually discover PCBs from a driver DriverGuard is not suitable for high speed devices (e.g., network card, disk) – The data in network and disk I/O are derived data – They can be encrypted by applications. ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows23

24. 24 Summary DriverGuard is a generic solution to dynamically protect I/O flows from devices to applications with low performance overhead DriverGuard can work jointly with user-space data protection schemes to safeguard the entire data lifecycle ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows24

25. 25 Thanks, Questions? ESORICS 2011DriverGuard: A Fine-grained Protection On I/O Flows25