Web browsers do not yet provide Web programs with the same safe, convenient access to local devices that operating systems provide to native programs. As a result, Web programmers must either wait for the slowly evolving HTML standard to add support for the device classes they want to use, or they must use difficult to deploy browser plug-ins to add the access they need. This paper describes Maverick, a browser that provides Web applications with safe and flexible access to local devices. Maverick lets Web programmers implement USB device drivers and frameworks, like file systems or streaming video layers, using standard Web programming technologies such as HTML, JavaScript, or even code executed in a native client sandbox. These Web drivers and Web frameworks are downloaded dynamically from Web servers and executed by browsers alongside Web applications. Maverick provides Web drivers with protected access to the USB bus, and it provides Web drivers and frameworks with event-driven IPC channels to communicate with each other and with Web applications. We prototyped Maverick by modifying the Chrome Web browser and the Linux kernel. Using Maverick, we have implemented: several Web drivers, including a USB mass storage driver and a Webcam driver; several Web frameworks, including a FAT16 filesystem and a streaming video framework; and, several Web applications that exercise them. Our experiments show that Web drivers, frameworks, and applications are practical, easy to author, and have sufficient performance, even when implemented in JavaScript. 1

Device drivers are the single largest contributor to operating-system kernel code with over 5 million lines of code in the Linux kernel, and cause significant complexity, bugs and development costs. Recent years have seen a flurry of research aimed at improving the reliability and simplifying the development of drivers. However, little is known about what constitutes this huge body of code beyond the small set of drivers used for research. In this paper, we study the source code of Linux drivers to understand what drivers actually do, how current research applies to them and what opportunities exist for future research. We determine whether assumptions made by driver research, such as that all drivers belong to a class, are indeed true. We also analyze driver code and abstractions to determine whether drivers can benefit from code re-organization or hardware trends. We develop a set of staticanalysis

The success of any commodity operating system is determined by the quality of device driver support. Over the last decades, the computer hardware industry has been advancing at a rapid pace, putting high pressure on device driver developers. About 52 % of the Linux kernel code is comprised by device drivers, accounting for close to 7.4 million lines of code. While managing such a huge code base is a challenge on its own, Linux device driver developers have to overcome additional obstacles. The complex, multithreaded programming model of the kernel creates a high potential for bugs and many of them result in kernel crashes. Device drivers constitute the largest and most unreliable component of the kernel. This thesis analyses the root causes of the device driver reliability problem, and demonstrates how the current driver programming model can be improved to assist programmers in creating better driver code. To examine and test feasible improvements, a prototype language (called CiD) based on a subset of C was designed with the special requirements on Linux device driver development in mind. CiD features syntactical additions for three essential device driver code aspects: concurrency, synchronization and hardware communication. The compiler is programmed

Device drivers are an Achilles ’ heel of modern commodity operating systems, accounting for far too many system failures. Previous work on driver reliability has focused on protecting the kernel from unsafe driver side-effects by interposing an invariant-checking layer at the driver interface, but otherwise treating the driver as a black box. In this paper, we propose and evaluate Guardrail, which is a more powerful framework for run-time driver analysis that performs decoupled, instruction-grain dynamic correctness checking on arbitrary kernel-mode drivers as they execute, thereby enabling the system to detect and mitigate more challenging correctness bugs (e.g., data races, uninitialized memory accesses) that cannot be detected by today’s fault isolation techniques. Our implementation of Guardrail demonstrates that it can find serious data races, memory faults, and DMA faults in native Linux drivers that required fixes, including previously unknown bugs. Also, we show that with hardware logging support, Guardrail can be used for online protection of persistent device state from defective drivers with minimal impact on the end-to-end