Understanding modern device drivers

Kadav, Asim; Swift, Michael M.

doi:10.1145/2189750.2150987

Cited by 5 publications

(3 citation statements)

References 29 publications

(12 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Kernel extensions, when loaded into the system can also export a subset of their functions to other extensions. 3 Ianus is an ancient Roman God who has two faces, each looking in the opposite direction. His image is associated with the ability of imagining two opposites or contradictory ideas existing simultaneously.…”

Section: Challenges For Hardware-software Cooperationmentioning

confidence: 99%

“…Kernel extensions, especially device drivers, currently make up a large fraction of modern kernel code bases (approximately 70% in Linux and a larger percentage in Windows) [3]. Most of these extensions are benign and allow the system to communicate with an increasing number of diverse I/O devices without the need of OS reboot or recompilation.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Hardware-software collaboration for secure coexistence with kernel extensions

Oliveira

Wetzel

Bucci

et al. 2014

SIGAPP Appl. Comput. Rev.

View full text Add to dashboard Cite

Our society is dependent upon computer systems that are the target of a never-ending siege against their resources. One powerful avenue for exploitation is the operating system kernel, which has complete control of a computer system's resources. The current methodology for kernel design, which involves loadable extensions from third parties, facilitates compromises. Most of these extensions are benign, but in general they pose a threat to system trustworthiness: they run as part of the kernel and some of them can be vulnerable or malicious. This situation is paradoxical from a security point of view: modern OSes depend, and must co-exist, with untrustworthy but needed extensions. Similarly, the immune system is continuously at war against various types of invaders and, through evolution, has developed highly successful defense mechanisms. Collaboration is one of these mechanisms, where many players throughout the body effectively communicate to share attack intelligence. Another mechanism is foreign body co-existence with its microbiota. Remarkably, these properties are not leveraged in kernel defense approaches. Security approaches at the OS and virtual machine layers do not cooperate with each other or with the hardware. This paper advocates a new paradigm for OS defense based on close collaboration between an OS and the hardware infrastructure, and describes a hardware-software architecture realizing this vision. It also discusses the architecture design at the OS and hardware levels, including experimental results from an emulator-based prototype, and aspects of an ongoing hardware implementation. The emulator-based proof-of-concept prototype, Ianus, uses Linux as the OS and the Bochs x86 emulator as the architecture layer. It successfully minimized kernel extensions interactions with the original kernel. Its security was evaluated with real rootkits and benign extensions. Ianus' performance was analyzed with system and CPU benchmarks and it caused a small overhead to the system (approximately 12%). 1

show abstract

Section: Challenges For Hardware-software Cooperationmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Hardware-software collaboration for secure coexistence with kernel extensions

Oliveira

Wetzel

Bucci

et al. 2014

SIGAPP Appl. Comput. Rev.

View full text Add to dashboard Cite

show abstract

“…However, many drivers have proprietary commands that cannot be captured by a shadow driver common to an entire class, leading to incomplete recovery. Recent work showed that up to 44% of drivers have non-class behavior [21].…”

Section: Not Enoughmentioning

confidence: 99%

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