Home > Articles > Operating Systems, Server

Introducing OpenBSD 3.9

  • Print
  • + Share This
Open Source expert David Chisnall gives us the ins and outs of where OpenBSD has been, where it is now with the new version 3.9, and what lies ahead in the future.
Like this article? We recommend

Like this article? We recommend

OpenBSD began life as a fork of NetBSD, the oldest of the currently active BSD projects. A personality clash between Theo de Raadt and the rest of the NetBSD team lead to Theo’s access to the project’s CVS tree being revoked.

At the time, the standard way of developing F/OSS was for a small group of developers to have access to a private CVS repository. They would then publish periodic snapshots of the tree for download. One of Theo’s first acts after leaving NetBSD was to create a public anonymous CVS server containing his local copy of the NetBSD tree, including the improvements he had not been allowed to commit to the main tree.

This transparency in the development process gave the new project the name OpenBSD. The openness is reflected in the project’s license philosophy. Most of the base system is BSD licensed, with a few MIT licensed or public domain pieces. A few GPL’d components, such as the GNU Compiler Collection, are permitted but only in cases where no alternative is available with a more permissive license. Closed-source code is not permitted in the base system at all.

Another feature of this openness, and something that sets OpenBSD apart from many other systems, is the documentation. In OpenBSD, the UNIX manual pages are considered authoritative. If a program or function call does not behave exactly as the manual describes, this is considered a bug. This is reflected in the development process, which does not allow any code that result in a user-visible change to be committed to the tree without an accompanying update to the documentation.

Within the last few years, OpenBSD has become more militant in its advocacy of openness. Prior to the 3.7 release, the team decided that its reverse-engineered drivers for several Adaptec cards did not meet the required quality for inclusion in the base system, and could not without documentation from the manufacturers. When this documentation was not provided, they removed support for Adaptec RAID hardware for the 3.7 release.

OpenBSD is also very unfriendly to the idea of drivers that rely on binary blobs; lumps of closed-source code that are loaded by an "open" driver. The NVIDIA drivers for Linux are an example of this; they provide a thin skeleton of open source code that is compiled and linked against the kernel which then loads the real, binary driver. Because the code for the real driver is not open, it cannot go through the same auditing process as the rest of the kernel, and so are likely to introduce bugs and security holes.

Some manufacturers are very reluctant to release the specifications required to create a driver. A common reason for this is that their product has a large number of bugs that are worked around by the driver. In some cases, it is because they heavily optimize a specific code-path used by a benchmark (sometimes even to the point of compromising accuracy) in order to gain a marketing advantage over their competitors.

The most common excuse given is that the documentation or the drivers contain valuable IP that they are not allowed to release, or do not wish to provide to their competitors. While this may be true of some complex graphics card drivers that include a significant portion of an OpenGL implementation in software, it is not true of the specification from which the drivers were created. To quote Marco Peereboom, one of the OpenBSD developers:

"One fills in a few structures, one hands it off to the hardware, one gets notified when the work is done. There that’s all a driver does. There is no IP in filling out a structure and handing it off to hardware."

Another example of OpenBSD’s activism came from the license restrictions placed on the firmware for wireless network cards. To save costs, most WiFi cards do not include their firmware in ROM. Instead, it is loaded by the driver at runtime. This means, obviously, that a working driver must have a copy of the card’s firmware. Unfortunately, most manufacturers placed redistribution restrictions on these firmware files, meaning that the end user had to download them directly from the manufacturer, rather than having them shipped with OpenBSD. Since then, most Southeast Asian manufacturers have modified their licenses to allow redistribution of the firmware.

In 2004, Theo De Raadt was presented with the Free Software Foundation’s Award for the Advancement of Free Software in recognition of these efforts.


The forked NetBSD code base that OpenBSD began with had a significant amount of history. It inherited code dating back to the first BSD releases in the 1970s. Some of this had never properly been audited or even read by anyone other than the original author. As such, it was full of small bugs, many of which were potential security holes.

In 1996, shortly after OpenBSD began, they started auditing the codebase. This is an ongoing process, and continues to this day. Every time a new type of bug is discovered, the entire codebase is searched to find other occurrences of it.

In spite of the audit process, the OpenBSD team admits that it (along with third-party developers) is not infallible. The OpenBSD kernel contains a number of features that protect against various categories of attack. More information about these can be found in the Security section of the OpenBSD web site.

  • + Share This
  • 🔖 Save To Your Account