How not to write Device Drivers

The recent installation of a new KVM switch has caused me to think a lot about device drivers. I have concluded that the current approach to writing device drivers is completely wrong.

The mistake is the idea that we should be coding device drivers at all.

This was brought home to me while installing the KVM switch on my locked down machine with absolute minimal user privileges. This required seven (count them!) different device drivers, none of which were signed despite the fact that they were all written by Microsoft. First the KVM switch announced itself as a USB hub. Then a 'Human Interface Device' driver was loaded to serve the mouse followed by a mouse specific driver. This was then repeated twice for the keyboard, the first time for the normal keyboard keys and the second time for the extra keys to do things like control audio volume.

Plug and play was a good idea, signing drivers was a good idea. The idea that every new device should add new code into the kernel space is terrible.

There will always be a few oddball devices that absolutely must use custom code. But 95% of devices should be able to use a small number of tried and tested generic drivers.

Today every model of every printer has its own driver. There must be at least 500 printer drivers that ship with Windows but the vast majority are simply variations on Postscript, PCL and the ancient Epson dot matrix codes.

Adding a disk drive to a system is much easier. There are built in generic drivers for all the common disk drive interfaces (IDE, SCSI, SATA, etc.)

Early experience with flash memory on the other hand was rather more mixed. Early flash memory would often insist on announcing itself as being made by a specific manufacturer resulting in tedious requests to load device drivers that were all the more irritating because the chips themselves were mostly made by the same two manufacturers who supplied them to a much larger number of companies who just had to put their own brand on them even if doing this caused the user to have to install an entirely unnecessary custom device driver.

Generic device drivers are safer and more convenient to install. The downside is that the current generic drivers do not provide the same functionality as a fully custom driver. The generic print drivers do not support choice of paper size, print trays and so on but there is no reason they should not. A simple printer capabilities query protocol would allow the pronter to tell the operating system the feature set it supports and the options the user may select. In the rare case that a printer did require support for a non-standard page description language the code to support this should run in application space and not the kernel.

Deciding that the driver of choice should be the generic driver has other dividends. The user interaction step in the device installation process can be bypassed completely. The driver can be pre-loaded into the operating system and configure automatically.

This is going to be increasingly important as the computer user is taken out of the administration loop for more and more operations and particularly as Virtual Machine technology is deployed to provide a line of defense against rootkits. Logging in to the machine with administrator privileges, even accessing the base machine is going to become increasingly difficult. This is not going to be acceptable if new code has to be inserted into the kernel to support every keyboard, mouse and web cam on the market.

Best of all the security issues that result from loading buggy or outright malicious device drivers are largely avoided. If a device driver is buggy it is much more likely to be patched.