Dealing with Driver Failures in the Storage Stack

Herder, Jorrit N.; Moolenbroek, David C. van; Appuswamy, Raja; Wu, Bingzheng; Gras, Ben; Tanenbaum, Andrew S.

doi:10.1109/ladc.2009.12

Cited by 7 publications

(2 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Detecting such corruptions would require end-to-end checks on data block contents', for instance by storing checksums alongside data, and verifying the checksum when retrieving data [18]. Some studies have introduced this kind of checks between the filesystem and the device driver [19], [20]. However, we note that the effectiveness of checksums is limited since data corruptions are detected only when such data is retrieved for reading, which may occur only after a long time has elapsed since the corruption.…”

Section: Related Workmentioning

confidence: 99%

MoIO: Run-time monitoring for I/O protocol violations in storage device drivers

Cotroneo

Simone

Fucci

et al. 2015

2015 IEEE 26th International Symposium on Software Reliability Engineering (ISSRE)

View full text Add to dashboard Cite

Bugs affecting storage device drivers include the so-called protocol violation bugs, which silently corrupt data and commands exchanged with I/O devices. Protocol violations are very difficult to prevent, since testing device driver is notoriously difficult. To address them, we present a monitoring approach for device drivers (MoIO) to detect HO protocol violations at run-time. The approach infers a model of the interactions between the storage device driver, the OS kernel, and the hardware (the device driver protocol) by analyzing execution traces. The model is then used as a reference for detecting violations in production. The approach has been designed to have a low overhead and to overcome the lack of source code and protocol documentation. We show that the approach is feasible and effective by applying it on the SATA/AHCI storage device driver of the Linux kernel, and by performing fault injection and long-running tests

show abstract

Section: Related Workmentioning

confidence: 99%

MoIO: Run-time monitoring for I/O protocol violations in storage device drivers

Cotroneo

Simone

Fucci

et al. 2015

2015 IEEE 26th International Symposium on Software Reliability Engineering (ISSRE)

View full text Add to dashboard Cite

show abstract

“…Failure of just one kernel component generally causes the entire system to crash. Major offenders are device drivers [20,23,28], which reportedly caused 65-83% of all crashes in Windows XP [20,28,41]. These components are numerous, hardware specific, and often less tested due to a more limited user base.…”

Section: Introductionmentioning

confidence: 99%

VirtuOS

Nikolaev

Back

2013

Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles

View full text Add to dashboard Cite

Most operating systems provide protection and isolation to user processes, but not to critical system components such as device drivers or other system code. Consequently, failures in these components often lead to system failures. VirtuOS is an operating system that exploits a new method of decomposition to protect against such failures. VirtuOS exploits virtualization to isolate and protect vertical slices of existing OS kernels in separate service domains. Each service domain represents a partition of an existing kernel, which implements a subset of that kernel's functionality. Unlike competing solutions that merely isolate device drivers, or cannot protect from malicious and vulnerable code, VirtuOS provides full protection of isolated system components. VirtuOS's user library dispatches system calls directly to service domains using an exceptionless system call model, avoiding the cost of a system call trap in many cases. We have implemented a prototype based on the Linux kernel and Xen hypervisor. We demonstrate the viability of our approach by creating and evaluating a network and a storage service domain. Our prototype can survive the failure of individual service domains while outperforming alternative approaches such as isolated driver domains and even exceeding the performance of native Linux for some multithreaded workloads. Thus, Vir-tuOS may provide a suitable basis for kernel decomposition while retaining compatibility with existing applications and good performance.

show abstract