OpenBSD 3.9: Blob-Busters Interviewedby Federico Biancuzzi
This release, like every OpenBSD release, contains OpenBSD and its source code. It runs on a wide variety of hardware. It contains many new features and improvements. OpenBSD attempts to convince vendors to release documentation and often reverse-engineers around the need for blobs. OpenBSD remains blob-free. Anyone can look at it, assess it, and improve it. If it breaks, it can be fixed.
Federico Biancuzzi interviewed OpenBSD's team of Blob-Busters and discussed new features of OpenBSD 3.9 along with freedom (and quality!) threats.
You have been fighting against binary-only drivers and firmware for years. Would you like to share some success stories?
Jonathan Gray: With such discussions you have to be careful to define the terms involved. Firmware does not run on your computer, it runs on the device in a separate address space. Things like PCMCIA, CardBus, and USB devices may seem really small but even these have a processor, and that is where the firmware is run. Traditionally, these devices have come with the firmware already on a ROM ready to go. In recent years, some devices have moved away from this model and required the firmware to be loaded into the device at runtime before it will work. This saves vendors some amount of money required to make the hardware.
The burden of dealing with the firmware is then put into the hands of the operating system. To have hardware just work we need to be able to include this firmware in OpenBSD. What we ask vendors for is the right to freely distribute the binary images required to make their products work. Atmel, Ralink, Zydas, and others have been really helpful in this regard; while others, like Intel, don't seem terribly keen on letting people use their hardware. You can do an install over wireless with a Ralink wireless device, this is something you can't do with the current Intel situation with Intel wireless devices. You have to read their license agreement and manually locate and download the correct firmware for your device before anything will work. The person responsible at Intel had their details listed in our documentation, the phone number has since been changed.
Drivers that are binary-only or contain a binary-only portion (binary blob) run on the computer, in the computer's memory. They typically run at the most privileged security level possible due to their requirements to talk to system memory and the like. This gives them access to anything on your system, and if they screw up it can be a disaster. These drivers are unportable and typically limited to a handful of architectures. With drivers that have full source available, people can see what the driver is doing and make corrections as required, this is something that can't be done with drivers that contain binary components. People who use binary drivers become dependent on the vendors who provide them for fixing bugs and if a vendor decides to drop the driver, you're out of luck. Not running the latest hardware with the latest approved software? Sorry, too bad.
There aren't any drivers in OpenBSD with binary-only components, this is quite a contrast to pretty much everyone else out there. We ask that vendors allow us to distribute their firmware freely and do not require source code for it.
Traditionally, 99% of Ethernet drivers in OpenBSD have been based on the efforts of Bill Paul in FreeBSD to support pretty much every kind of Ethernet device under the sun. So, naturally there was a point where Bill asked NVIDIA for documentation to the onboard Ethernet in their nForce products, and it would appear they turned him down as he moved onto working on other things. Sometime later, some other people did what is depressingly more and more common in FreeBSD, they included a driver that is a thinly-veiled wrapper around a binary blob. They even had to get a license specific to FreeBSD to distribute it. This is a horrific scenario we would never consider doing in OpenBSD.
Sometime later, I had access to a machine with nForce Ethernet and started writing a driver with full source code even though we still did not have documentation. Some information as to how the thing works was derived from a reverse-engineered Linux driver. Damien Bergamini later came on board to help get it working in time for 3.9.
This kind of thing is happening all the time, we spend large amounts of time trying to get vendors to give us documentation and rights to distribute their firmware so that their hardware will function as something more than expensive paper weights.
OpenBSD 3.9 has had lot of work done to support management sensors (fans, temperature, power, etc.). Did you have any problem finding the docs to write appropriate drivers? Do they use standard protocols, or each manufacturer reinvents the wheel on his own? How do you handle hardware bugs or "improvements" to the standard made by a single manufacturer?
Marco Peereboom: This is really exciting stuff and was written by lots of people. Jordan Hargrave wrote the bulk of the IPMI code and shared his previously written ESM stuff with David Gwynne. Mark Kettenis, Alexander Yurchenko, and Theo de Raadt (many others worked on it but they did the bulk of the work) revamped the I2C stuff and we now support most I2C devices.
The I2C devices are well documented, however, that doesn't mean that everything is hooked up as expected. Vendors use those parts in different ways and sometimes that results in unexpected behavior. Theo and Mark did an amazing job working around most of the hardware issues and improvements as you call them.
IPMI is a standard, but there are vendors out there that have reading comprehension issues. Due to this we still have some quirks that need to be addressed.
Overall, we still need to improve the sensors framework itself. Currently, it's a little tedious to maintain a farm of servers. There are some developments but nothing concrete yet. I do expect this to get a lot of attention in the near future so look out for some innovation in this area.
Can you elaborate on where the sensors framework is heading in the future?
David Gwynne: The main goal of the sensors framework is to support as many different environmental sensors as possible and provide a uniform interface on top of them.
Currently, we have about 30 drivers in the tree for a wide variety of hardware on a variety of different architectures. Sensors are everywhere. The devices we support range from simple I2C and ISA devices all the way up to the sensors on SCSI enclosures and the management controllers found in servers. Despite the differences between all these sensors they are all part of the same framework and they all appear in the same way to the user. Most of these drivers were written in the last six months.
Due to the prevalence of sensors in most modern hardware and the new drivers in 3.9, a lot of people will be pleased to discover that they can now see the state of their sensors simply by going
Our goal in the future is to keep expanding this device support and to refine the user interface to it. For example, there is a small daemon called sensorsd that is currently in the tree and part of 3.9, but it is ugly and hard to configure. We're hoping to replace it in this development cycle and provide a default configuration that just works. If we can do this we can enable it by default.
Some of the more intelligent hardware is integrated with a hardware watchdog, but the watchdog API and the sensors framework don't fit together well on the same hardware. Some of the same hardware also has the ability to log events. I intend to work on these two areas in the future as well.