slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines PowerPoint Presentation
Download Presentation
Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines

Loading in 2 Seconds...

play fullscreen
1 / 18

Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines' - dorie

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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



  • 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



  • Wrap device drivers in virtual machines
  • Use of a device driver is translated into a client-server transaction


Client Virtual

Machine 2(Linux

DD Virtual

Machine 2 (Linux 2.4.22)

Client Virtual

Machine 1 (Linux

DD Virtual

Machine 1 (Linux 2.4.22)



File system

File system

OS Services

OS Services

Guest OS



















Translation Modules

Translation Modules

I/O Request


VMM (User level L4 task)




as a trap)

Hypervisor (L4 Microkernel)



  • 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

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

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
direct memory access dma
Direct Memory Access (DMA)



(Courtesy to Jonathan Walpole)


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

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


  • 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

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


  • 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

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

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
discussion 2
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)