The design and implementation of microdrivers

Ganapathy, Vinod; Renzelmann, Matthew J.; Balakrishnan, Arini; Swift, Michael M.; Jha, Somesh

doi:10.1145/1353536.1346303

Cited by 25 publications

(42 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Existing program partitioning tools statically partition user mode code or move driver code to user mode [16]. FGFT is the first system to partition programs within the kernel and is hence able to provide partitioning benefits to kernel specific components such as interrupt delivery and critical I/O path code.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Fine-grained fault tolerance using device checkpoints

2013

Self Cite

View full text Add to dashboard Cite

Recovering faults in drivers is difficult compared to other code because their state is spread across both memory and a device. Existing driver fault-tolerance mechanisms either restart the driver and discard its state, which can break applications, or require an extensive logging mechanism to replay requests and recreate driver state. Even logging may be insufficient, though, if the semantics of requests are ambiguous. In addition, these systems either require large subsystems that must be kept up-to-date as the kernel changes, or require substantial rewriting of drivers.We present a new driver fault-tolerance mechanism that provides fine-grained control over the code protected. Fine-Grained Fault Tolerance (FGFT) isolates driver code at the granularity of a single entry point. It executes driver code as a transaction, allowing roll back if the driver fails. We develop a novel checkpointing mechanism to save and restore device state using existing powermanagement code. Unlike past systems, FGFT can be incrementally deployed in a single driver without the need for a large kernel subsystem, but at the cost of small modifications to the driver.In the evaluation, we show that FGFT can have almost zero runtime cost in many cases, and that checkpoint-based recovery can reduce the duration of a failure by 79% compared to restarting the driver. Finally, we show that applying FGFT to a driver requires little effort, and the majority of drivers in common classes already contain the power-management code needed for checkpoint/restore.

show abstract

Section: Related Workmentioning

confidence: 99%

“…Faulty device drivers cause many reliability issues in these systems [8,37]. Hence, there has been significant research to tolerate driver failures using programming-language and hardware-protection techniques [3,6,15,16,23,26,46]. These systems execute the entire driver as a single isolated component.…”

Section: Introductionmentioning

confidence: 99%

Fine-grained fault tolerance using device checkpoints

2013

Self Cite

View full text Add to dashboard Cite

show abstract

“…SafeDrive [25] improves kernel extension reliability by adding type-based checking to driver code and enforcing runtime memory safety. In order to leverage user level programming tools and reduce kernel level faults introduced by drivers, Microdriver [26] partitions an existing driver into a kernel level driver handling performance critical tasks and a user level driver processing low-performance issues. The Nexus [27] operating system moves the device driver to user space and it leverages devicespecific reference monitors to validate that all the interactions between drivers and devices conform to safety specifications.…”

Section: Related Workmentioning

confidence: 99%

DRIP: A framework for purifying trojaned kernel drivers

Sumner

Deng

et al. 2013

2013 43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)

View full text Add to dashboard Cite

Abstract-Kernel drivers are usually provided in the form of loadable kernel extensions, which can be loaded/unloaded dynamically at runtime and execute with the same privilege as the core operating system kernel. The unrestricted security access from the drivers to the kernel is nevertheless a double-edged sword that makes them susceptible targets of trojan attacks. Given a benign driver, it is now easy to implant malicious logic with existing hacking tools. Once implanted, such malicious logic is difficult to detect.In this paper we propose DRIP, a framework for detecting and eliminating malicious logic embedded in a kernel driver through iteratively eliminating unnecessary kernel API invocations from the driver. When provided with the binary of a trojaned driver, DRIP generates a purified driver with benign functionalities preserved and malicious ones eliminated. Our evaluation shows that DRIP successfully eliminates malicious effects of trojaned drivers in the system, with the purified drivers maintaining or even improving their performance over the trojaned drivers.

show abstract

“…However, SUD cannot be applied to the hosted hypervisors such as KVM simply because that hardware virtualization extension (e.g., Intel VT) is not constrained by the IOMMU or other hardware mechanisms that SUD relies on. Microdrivers [15] reduces device driver's TCB in the kernel by slicing the driver into a privileged performancecritical kernel part and the remaining unprivileged user part. RVM [41] executes device drivers in the user space and uses a reference monitor to validate interactions between a driver and its corresponding device.…”

Section: Related Workmentioning

confidence: 99%

Isolating commodity hosted hypervisors with HyperLock

Wang

Grace

et al. 2012

Proceedings of the 7th ACM European Conference on Computer Systems

View full text Add to dashboard Cite

Hosted hypervisors (e.g., KVM) are being widely deployed. One key reason is that they can effectively take advantage of the mature features and broad user bases of commodity operating systems. However, they are not immune to exploitable software bugs. Particularly, due to the close integration with the host and the unique presence underneath guest virtual machines, a hosted hypervisor -if compromised -can also jeopardize the host system and completely take over all guests in the same physical machine.In this paper, we present HyperLock, a systematic approach to strictly isolate privileged, but potentially vulnerable, hosted hypervisors from compromising the host OSs. Specifically, we provide a secure hypervisor isolation runtime with its own separated address space and a restricted instruction set for safe execution. In addition, we propose another technique, i.e., hypervisor shadowing, to efficiently create a separate shadow hypervisor and pair it with each guest so that a compromised hypervisor can affect only the paired guest, not others. We have built a proof-ofconcept HyperLock prototype to confine the popular KVM hypervisor on Linux. Our results show that HyperLock has a much smaller (12%) trusted computing base (TCB) than the original KVM. Moreover, our system completely removes QEMU, the companion user program of KVM (with > 531K SLOC), from the TCB. The security experiments and performance measurements also demonstrated the practicality and effectiveness of our approach.

show abstract

The design and implementation of microdrivers

Cited by 25 publications

References 13 publications

Fine-grained fault tolerance using device checkpoints

Fine-grained fault tolerance using device checkpoints

DRIP: A framework for purifying trojaned kernel drivers

Isolating commodity hosted hypervisors with HyperLock

Contact Info

Product

Resources

About