Device drivers are a seldom-discussed but vital component of all computer operating systems. They are the (relatively) small bits of software “glue” that allow the system to communicate with specific devices. They translate a general functional request from the system (such as, read the next block of a file) into the specific device commands needed to accomplish it. (Readers who are old enough to have used a word processor, like WordPerfect, from the MS-DOS era, may remember that getting the right printer driver installed was crucial to getting good-quality output. A driver for an HP LaserJet II just would not work with a PostScript printer, for example.) Although most drivers are not large individually, a typical system requires quite a few of them. It is estimated, for example, that more than 60% of the code in a typical Linux installation is device drivers.
Device drivers are also a pain in the neck, for several reasons. Device manufacturers know that they will not be able to sell their whizzy new gadgets unless they also provide drivers for popular operating environments (meaning in practice, Microsoft Windows, and to some extent Mac OS X). Often, the development of these drivers is outsourced, and the goal is to produce something quickly that more-or-less works. Drivers for Linux are often not provided by the device manufacturer; sometimes, the manufacturer will not even provide the interface specifications, which have to be reverse-engineered. (The fact that many drivers have been developed in just this way is a tribute to the ingenuity of their open-source developers.) Regardless of how they are developed, though, the drivers are largely invisible to the user (at least until they fail), and are not really the focus of anyone’s attention. Software and device vendors tend to focus on product features, and users generally install whatever drivers are provided without much thought.
This is unfortunate, because device drivers have a very significant capacity to cause trouble. They typically run as extensions of the core operating system, at the highest execution privilege level. This means that bugs in a driver can crash the entire system, and that security vulnerabilities in a driver can lead to a complete breakdown of system security. (Even back in the days of the IBM System/360 mainframes, the hacker’s preferred route to attack system security was via device drivers.) Microsoft researchers have estimated that ~85% of Windows crashes are caused by device driver problems. Examination of the code in Linux device drivers, compared to the code in the Linux kernel, indicates an error rate in the driver code that is 3-7 times that of the kernel code.
At the recent USENIX Annual Technical Conference in Boston, Vitaly Chipounov, of the École Polytechnique Fédérale de Lausanne (EPFL) in Switzerland, presented a paper [PDF] describing a new tool that he and his colleagues have developed for testing device drivers. The tool, called DDT, is particularly interesting because it allows testing of binary drivers for which the source code is unavailable. It does this by executing the driver in a virtual machine environment, using a specialized symbolic execution engine to exercise the driver thoroughly. When it finds suspect results, it provides an execution trace of how things went wrong.
The team tested six Microsoft-certified device drivers for Windows, from four different vendors, with code segments ranging in size from 14 to 120 KB, and containing from 48 to 525 functions. They discovered 14 previously unreported serious bugs in these drivers. (I was interested to see that one of the common causes of driver bugs was the driver’s failure to check error status when a kernel function call returned. This is completely consistent with my personal observation of software development: some programmers seem to have difficulty understanding that error return codes exist for a reason.)
The Technology Review has a short article with an overview of this work. The tool, at present, is basically a prototype, which currently works only for Windows drivers. However, the concept seems sound; and getting better quality drivers would make everyone’s life easier.