DriverGuard: A Fine-grained Protection On I/O Flows Yueqiang Cheng, Xuhua Ding and Robert H. Deng School of Information Systems Singapore Management University

DriverGuard: A Fine-grained Protection On I/O

FlowsYueqiang Cheng, Xuhua Ding and

Robert H. DengSchool of Information SystemsSchool of Information Systems

Singapore Management UniversitySingapore Management University

The 16th European Symposium on Research in Computer Security (ESORICS), 12-14 Sep 2011, Leuven (Belgium)

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 2011 DriverGuard: A Fine-grained Protection On I/O Flows 2

3

Typical I/O Flow


Data regionsI/O ports or MMIODriver bufferskernel stacksUser-space regions

So many possible target interfaces and regions for

attackers

Device I/O Interfaces

I/O portsMemory-Mapped IO (MMIO)DMA

4

No Good Existing Solutions


device Driver Application 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

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


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


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


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


9

Features of Drivers (cont.)

• DriverGuard distinguishes code blocks, which issue commands or need to know the content of data, from other driver code


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

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


Hypervisor with DriverGuard

Device

Driver

Application

Guest Kernel

User Space

11

Our Approach in DriverGuard


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

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.


• Command-PCB and Computation-PCB are original driver code; key-PCBs are introduced as library functions called by drivers.

13

Key-PCB

• 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.


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)


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



Device

Driver with PCBs…

Guest Kernel

Application

User Space

16

1. Driver gets read request from user space


Example with TypicalInput Flow (cont.)


Device

Driver with PCBs…

ApplicationUser

Space

DMA buffer

Driver buffer

Data buffer

Guest KernelRequesta) 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


2. Device uses DMA to transfer data into DMA buffer, and generates an interrupt



Device

Driver with PCBs…

ApplicationUser

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 grant

Encrypting

Plain text

Cipher text

18

Example with TypicalInput Flow (cont.)4. A PCB may do

computation operations on data



Device

Driver with PCBs…

ApplicationUser

Space

DMA buffer

Driver buffer

Data buffer

DMA buffer

Plain text

Driver Execution Flow In PCB execution

Decrypting Encrypting

Cipher text

Cipher text

Guest Kernel

19

5. Data movementDo not need to know

the content of dataNot need PCBs




Device

Driver with PCBs…

Application

User Space

Data buffer

6. Finally data is transferred into user space The data is decrypted

DMA buffer

Driver buffer

Data buffer

Driver buffer

Guest Kernel

20

PCB Execution Escorting


If the PCB is scheduled off CPUDriverGuard sets the data region(s) inaccessibleDriverGuard prepares a fake kernel stack to prevent attackers getting sensitive information from stack

Cipher text

Plain text

Plain text

Plain text

Cipher text

Off CPU On CPU

Driver Execution Flow

In PCB execution

Out of PCB execution

Decrypting Access Denied

Access Grant Encrypting

If the PCB is scheduled on CPUDriverGuard sets the data region(s) accessible.DriverGuard restores the original kernel stack

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)


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


Keyboard input transfer

Camera waiting

Fingerprint collection

1 page print

Sound card open

Without DriverGuard

0.053ms 33.24ms 2.61s 15.74s 7.8 μs

With DriverGuard 0.138ms 33.38ms 2.63s 16.19s 12.3μs

Percentage 160.40% 0.42% 0.77% 2.86% 57.7%

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.


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


25

Thanks, Questions?


Documents

DriverGuard: A Fine-grained Protection On I/O Flows Yueqiang Cheng, Xuhua Ding and Robert H. Deng School of Information Systems Singapore Management University