The Role of Binary Drivers in a Free OS
Date: Aug 4, 2006
The Arguments
There’s a lot of controversy over whether a Free Software operating system should include binary-only drivers. Arguments on both sides range from the philosophical to the practical, all of which are worth examining.
Before we look at whether there should be binary drivers in a free OS, it’s worth looking at what exists at the moment. The most hard-line platform in this area is OpenBSD, which flatly refuses to allow binary blobs in kernelspace, citing reliability and security concerns. FreeBSD is a different matter; it includes some binary drivers for things like RAID chipsets in the base system.
The situation in the Linux world is even more interesting. The Linux kernel doesn’t allow binary drivers at all. By changing the kernel APIs and ABIs periodically, the developers actively discourage anyone from writing a driver—open or closed—that’s maintained outside the main tree.
But few people build Linux systems themselves; most use a distribution. Most Linux distributions don’t use the stock kernel—they use their own in-house version. This version usually isn’t different enough from the main trunk to be considered a fork, but has some patches installed. The distribution may also bundle some extra drivers. Many binary drivers have licenses that prohibit redistribution, but it’s not uncommon for distributions—even LiveCDs such as Knoppix—to include scripts that automatically download and install drivers after boot.
Binary drivers are a fact of life for a lot of Free Software users. Does it matter?
Quality
The quality argument is used by both sides. A spokesman for NVIDIA recently argued that there was no point in releasing the specifications for NVIDIA’s cards, because no one outside their organization had the skill required to write a competent driver. This statement may indeed be true. They may have completely cornered the market in people who are able to write good display drivers. It seems unlikely, however.
A few years ago, I owned a desktop with an ATI R200 series GPU and a SoundBlaster Live! audio device. This machine ran Windows 2000, and crashed periodically; usually just under once a week. When Windows crashes, it displays a tasteful shade of blue with debugging information written all over it. This invariably told me that one of two things had caused the crash:
- The Creative Labs drivers
- The ATI drivers
I later migrated to FreeBSD on this machine. The sound card used drivers written by the FreeBSD team, and the graphics card used drivers written by the DRI Group. The difference? Suddenly my machine was stable.
My experience with manufacturer’s drivers hasn’t been good, whereas my experience with open source drivers (where they exist) has been excellent. Perhaps I’m unusual in this respect.
Security
The OpenBSD team’s main argument against binary drivers is that they harm system security. OpenBSD has a reputation for having first-rate security because every part of the system is under a constant process or code review.
If you run a piece of unaudited (or malicious) code in userspace on OpenBSD, some mechanisms are in place to attempt to mitigate vulnerabilities. Sometimes these features aren’t enough, and then it’s a matter of damage control. Fortunately, most services run with limited privileges. If a web application is compromised on an OpenBSD box, the attacker can’t touch anything that the web server couldn’t touch—usually limited to a very small set of tightly controlled data.
The situation is somewhat different if the compromised code is in kernelspace. By necessity, the kernel runs in the highest privilege mode, and therefore can do anything—access any device, inspect any bit of memory. Once an attacker has compromised the kernel, the only safe thing to do is erase the disk and reinstall.
This aspect recently became visible with the discovery of a security hole in a binary driver for a WiFi card that allows a machine to be compromised by any attacker within WiFi range (about 100 meters, in good conditions).
Trade Secrets
One argument commonly given by manufacturers is that releasing their code, or its documentation, would cost them competitive advantage. In some cases, this complaint makes sense. In the graphics accelerator market, for example, a lot of optimizations are done in software. If a competitor could examine these improvements in detail, the original manufacturer might lose some of its edge. Since a significant amount of money is spent designing and implementing these optimizations, a company could conceivably gain an advantage by investing more in hardware design and copying the driver innovations from competitors.
This situations seem somewhat unlikely, however, because most hardware in which such things are important is sufficiently complex (and varies enough between manufacturers) that an optimization for one would have the opposite result on another.
Where this argument fails is in relation to interface specifications. Hardware interface specifications have very little by way of implementation details. They tell you which registers you have to set for a particular action, for example. The internal implementation is significantly more complicated. Consider the Pentium II and the Athlon; both execute almost the same instruction set—they have the same interface—but their implementations are wildly different.
Some graphics card manufacturers have claimed in the past that their drivers included code licensed from third parties. In this case, they wouldn’t be able to release that portion of the code. It’s worth noting that this can be a very real concern. When Sun bought StarOffice, it took a long time for Sun to perform a full audit on the code and discover which parts they now owned (and release those bits) and which parts were merely licensed. A similar process is currently underway with Solaris. It may not always be economically feasible to identify which parts of a driver could be released without legal issues. But this wouldn’t stop them from releasing the specifications.
Bad Hardware
One slightly more credible reason for not releasing documentation is that the driver works around broken behavior in the hardware, and the manufacturer doesn’t want to announce to the world how bad its hardware really is.
A good example of this problem is the Realtek 8139 Ethernet controller chip. The OpenBSD driver for this chip begins with a comment containing choice phrases such as "I’m inclined to blame this on crummy design/construction on the part of Realtek...." The FreeBSD driver is even more scathing. The file begins this way:
The Realtek 8139 PCI NIC redefines the meaning of "low end." This is probably the worst PCI Ethernet controller ever made, with the possible exception of the FEAST chip made by SMC.
Has this bad press affected the chip’s popularity? Not in the slightest. Almost everyone I know owns at least one device containing this chip. In spite of the poor design, these chips are very popular among Free Software users due to the low price and the fact that the chips work with the user’s OS of choice (even if the chips don’t work as well as a more expensive version).
The Specifications Don’t Exist
While not commonly used as an excuse, this is the most probable reason for hardware manufacturers not releasing specifications for their devices. The driver team within the company may well be operating from incomplete specs, or even from something a bit closer to the implementation.
If there is no specification of release quality, the only way to release one is to write it. This requirement can be costly and, since it doesn’t directly lead to greater profits, it might be difficult to persuade a company’s management that writing specs is in their best interest.
The existence of good hardware documentation for the driver team, internal or external, usually results in a better quality driver. If lack of documentation is the reason why a company cannot release a detailed specification, some caution is probably advisable when considering relying on that manufacturer’s driver.
Conclusion
A lot of reasons are given for not supporting the development of Free Software drivers, either by releasing the code or the documentation required for other people to write them. Some of these arguments are valid, but most are misguided or simply wrong, particularly those that relate to not releasing the documentation required for other people to implement the drivers.
Whether you should use a binary driver with a Free Software operating system depends on why you chose a Free OS in the first place. If it was for transparency, security, stability, accountability, or the concept of Software Freedom, then a binary driver is likely to remove some of this attraction for you. If you had other reasons, perhaps using binary drivers is a more "pragmatic" solution.