BSD: The Other Free UNIX Family

Date: Jan 20, 2006 By David Chisnall.

There are a lot of options in the Free UNIX market at the moment. Everyone's favorite buzzword is Linux, and Sun is in the process of releasing Solaris under a Free Software license. One family, however, receives less attention than it is due. Berkeley Software Distribution (BSD) has grown into almost a complete replacement for UNIX, with numerous enhancements. David Chisnall explains why the BSD family has found its way into a large number of systems and what these systems can do for you.

There are a lot of options in the Free UNIX market at the moment. Everyone’s favorite buzzword is Linux, and Sun is in the process of releasing Solaris under a Free Software license. One family, however, receives less attention than it is due.
On March 9, 1978, the University of California at Berkeley released a set of patches to the Sixth Edition of the UNIX Timesharing System. These patches were licensed very permissively—you could do pretty much anything with them, but you had to state that a product that used them did so. The advertising clause was later dropped, and any distribution in source or binary form was allowed, providing the copyright notice was retained.

The name of this patch set was the Berkeley Software Distribution—BSD for short—and it gradually grew into almost a complete replacement for UNIX, with numerous enhancements.
A few years later, the owners of the UNIX original copyright decided to try to cash in on their system’s success, and sued UCB. The upshot was a small number of files containing original UNIX code were rewritten, and a completely unencumbered version of BSD—UNIX being dropped from the name for trademark reasons.

In the early ’90s, Intel released a microprocessor that was capable of running a real operating system. The Intel 386 included features such as support for paged virtual memory, so it became a potential target for running BSD. In 1991, Bill Jolitz released 386 BSD and then neglected the project. A group of people, frustrated by the difficulty of getting patches accepted to 386 BSD, began distributing a patch set and then a complete system known as FreeBSD.

At about the same time, BSD Networking Release/2 (one of the last releases by UCB) was adopted by a group known as NetBSD. While the FreeBSD team focused on supporting the Intel 386, the NetBSD team was keen to retain the portable nature of the original BSD code.
In 1995, a clash of personalities lead to one of the NetBSD core developers, Theo De Raadt, forking the project and creating OpenBSD. OpenBSD, being based in Canada, was not subject to the stringent export laws that the USA placed on cryptography at the time, and so became a popular operating system among the security-conscious. This lead to a thorough code review, which found a large number of bugs and security holes in the code imported from NetBSD. This code review is an ongoing part of the OpenBSD development process and allows them to boast an excellent security record.

Over the years, BSD code has found its way into a large number of systems. Many commercial UNIX variants began as forks of BSD code, and a BSD TCP/IP stack was used in earlier versions of Windows. BSD was also very popular in academia. One project, the Mach Microkernel at CMU, used a modified version of BSD to run UNIX programs. The Mach project was used by a company called NeXT as the foundation for their operating system. When NeXT was bought by Apple, a lot of the old BSD code was replaced with code from the NetBSD and FreeBSD projects. Mac OS X can be thought of as a close cousin to the BSD family: Although it uses Mach as an abstraction layer, much of the kernel is BSD-derived.

It is worth noting that the BSDs are complete systems. Linux is just a kernel, and to be useful it is usually combined with the GNU userland. The BSDs include their own userland—although some parts, such as the compiler, are imported from the GNU project. A BSD system can be installed with no third-party applications—and work. It is more common, however, to add additional packages such as X.org and a desktop environment (the same applications traditionally run atop Linux).

The FreeBSD project underwent some radical changes between versions 4 and 5. Much of the kernel was redesigned to better support multiprocessor systems. One developer, Matt Dillon, was unhappy with the direction it was going, so he set up Dragonfly BSD, a fork of FreeBSD 4. While FreeBSD 5 and later use a system of shared resources and locks, Dragonfly BSD uses message passing between concurrent threads—a process common on microkernel operating systems including Amiga OS (where Matt Dillon first made a name for himself).
Dragonfly BSD is designed as a cluster operating system, and should be able to be installed on a cluster of machines, presenting the appearance of a single large multiprocessor machine to end users.

FreeBSD

FreeBSD is the most popular of the BSD family. It is traditionally known for stability and performance. Many web servers are still around running versions of FreeBSD from years ago without a reboot. FreeBSD is developed in three branches: -CURRENT, -STABLE, and -RELEASE. Anything new is added to -CURRENT, which may or may not work at any given time. Once a new feature has undergone testing by the development team, it is added to -STABLE. Periodically, a release is created. These releases have a version number and their own branch in the CVS tree. Only bug fixes are allowed to be introduced into -RELEASE branches—no new features. This makes tracking a -RELEASE branch the thing to do if you want a completely stable system.

FreeBSD development underwent something of a hiccup around version 5. The release schedule was feature-based, and a large number of new features were planned. Gradually, the release date for FreeBSD 5 slipped farther and farther back. During this time, the project moved to the same six-month release schedule as NetBSD and OpenBSD.
The current release version is 6.0, which is the system used on the laptop on which this article is being written. The 5.x series was highly ambitious and the lack of immediate success gave it a reputation for being unstable and slow—the lack of speed coming from the large quantities of debugging code found in releases.

The 6.x series is intended to avoid the stigma associated with the 5.x series. One of the most noticeable improvements is the new scheduler, known as ULE. ULE is not enabled by default because it does not achieve quite as good throughput as the traditional 4BSD scheduler, making it worse for server roles. For desktop (or laptop) use, it is much better. ULE prioritizes processes that spend most of their time waiting: interactive processes. On this somewhat aging laptop, it is possible to do a large compile in the background without any loss of responsiveness in X applications.

Installation of third-party software is done using the ports system. Each port is a Makefile, containing the files that must be downloaded to build the program and a set of patches to make it run on FreeBSD. The ports system will automatically resolve dependencies when installing programs.

Every port can be compiled into a binary package, and there are copies available from the FreeBSD FTP mirrors (although they often lag behind the port version by several days).
For the few closed-source programs that require Linux, FreeBSD includes a Linux ABI compatibility layer, which translates system call vectors into their equivalent on FreeBSD. It also includes a Linux-style /proc file system for programs that depend on it. Shared libraries used by Linux programs can also be installed—the ports tree contains copies of the basic packages found in several popular Linux distributions.

FreeBSD has a couple of features that make it attractive for home users. First, nVidia release graphics drivers for it, giving it the same level of 3D acceleration available to Linux on nVidia hardware. Second, it includes Project Evil, a reimplementation of the NDIS driver API used by wireless networking cards on Windows, allowing many WiFi cards to be used without direct hardware support.

Project Evil is also being ported to NetBSD, which also has Linux ABI support. Note that ABI support is not full emulation. All UNIX systems have a set of system calls—functions handled by the kernel—which are all assigned numbers. These numbers and the system call arguments vary depending on the kernel. The ABI compatibility layer simply remaps the arguments and changes the number, giving almost no performance penalty—in some cases, even faster performance than native due to a better kernel implementation. Linux is not the only non-native ABI supported by these systems—NetBSD even includes a rudimentary Darwin ABI that allows some OS X applications to run.

NetBSD

The NetBSD tag line is "of course it runs NetBSD," and a long-running joke was that NetBSD was the OS you ran on your toaster. This ceased to be a joke a few months ago when the NetBSD team proudly demonstrated a toaster running their OS.

BSD has traditionally been easy to port to new architectures. The system contains a few platform-specific files, and the rest of the code uses an abstraction layer to implement features. The memory subsystem, for example, has a handful of (simple) platform-dependent functions, with the vast majority being implemented in a cross-platform way.

NetBSD builds on this. NetBSD 2.1 was released with support for 48 architectures. In the context of NetBSD, support for an architecture means that a boot-loader exists, can boot the kernel, and all of the userland components in the base system work.

NetBSD makes extensive use of cross-compilation. The entire system can be built on any platform that runs NetBSD (and some others) for any hardware running NetBSD. For example, it is possible to use a fast Windows machine to build NetBSD using the Cygwin POSIX emulation layer to install it on an old m68K Mac that would take a week or two to built the system itself. Thus, it is easy to test NetBSD on less-powerful hardware because every change can be compiled easily on a faster machine.

Recently, NetBSD has begun to focus more on performance. The new threading system is based on an N:M model, where the kernel schedules N threads, and a userspace scheduler multiplexes this to M user-visible threads. This is the same model used by Solaris, which is well-known for its multithreading performance, and similar to that used by FreeBSD 5 and later.
Many people who don’t use NetBSD are familiar with it because of pkgsrc, the system used for distributing third-party applications. pkgsrc runs on a number of other operating systems, including the Solaris and Mac OS X, and the NetBSD team recently received a donation from Sun to help the Solaris support.

The focus on portability gives NetBSD a very clean code base, making it a good system to study in an academic setting. One side effect is that it is often chosen as a base when implementing experimental new features. If these features are successful, they usually end up being ported to the other BSDs.

OpenBSD

OpenBSD claims to be "secure by default," and anyone who runs it gets a warm fuzzy feeling reading security advisories in popular programs with "does not affect OpenBSD" written at the bottom of the list of affected platforms.
The entire base system—kernel and userland—in OpenBSD undergoes a constant process of code review. When a new bug is discovered, the next step is to categorize it and search the rest of the tree for occurrences of the same type of bug.

This stringent checking is nice, but it applies only to the base system. Any third-party applications installed are not checked. To help reduce the problems, OpenBSD includes a number of security features.

No memory allocated by an OpenBSD program can be both writable and executable at the same time. Most operating systems support this on the x86 latest chips that support the NX bit, but OpenBSD supports it using the segment based protection mechanisms that have been available in all x86 chips for over a decade—and on other architectures.

A random gap is inserted between stack frames, making stack-smashing exploits much harder. This is combined with a "canary" value that is placed at the bottom of each stack frame and checked before returning to ensure that it has not been tampered with.

Allocated memory is inserted at a random location in a process’s address space, making it much harder for an attacker to guess where something interesting lies. There are many other mechanisms provided, and enabled by default, for ensuring an OpenBSD box remains secure.
Besides these features, OpenBSD pioneered a number of security features now found on other systems, such as SSH and sudo. The OpenBSD version of Apache, for example, runs in a chroot jail by default, so attackers who compromise Apache cannot do anything other than break the web server—they can’t even modify the contents of the web site on disk.

The downside is that badly written applications are more likely to crash on OpenBSD—something the authors consider vastly better than being exploited. Recent security enhancements to the memory allocation system resulted in X crashing regularly on OpenBSD. Further investigation revealed a bug that had existed for more than a decade in the X code, which had undoubtedly caused countless unexplained crashes.

OpenBSD, like NetBSD, is a very clean system and is designed to be easy to administer from the command line. While all of the BSDs have good documentation (the FreeBSD handbook in particular), the OpenBSD man pages are first rate. Nothing is allowed into the OpenBSD system that is user-visible unless it is accompanied by documentation, and the man pages are considered authoritative. The first place to look for documentation on OpenBSD is the manual; if it’s not there, there’s probably a bug.

The superb documentation available in the BSD community tends to make people who ask questions that are easily answered very unpopular. It is common for a question posted about a BSD system to be answered with a one-line reply instructing the asker to read the manual, This is good advice; the answer is usually there.

The OpenBSD packages system is currently the worst of the bunch. For a long time, upgrading the base system (a new release of which comes around every six months) meant deleting all installed packages and starting again. OpenBSD 3.7 added support for upgrading, but only of individual packages. OpenBSD 3.8 provided a full update facility, although it is considered experimental. OpenBSD 3.9 is expected to bring the package management system up to a more competitive level.

Others

There are a few other systems built on top of the main BSDs. PC BSD, which is a modified version of FreeBSD, is aimed more at the desktop. It features a graphical installer and a set of default packages targeted at a desktop user. M0n0wall is another FreeBSD-derived system designed for use in firewalls.

There are also a few commercial BSD-derived products available. Contrary to the belief prevalent in the Linux community, many of them do contribute code back to the parent projects, even though the license does not require them to. BSDI, the company behind BSD/OS, was a long-time financial supporter of the FreeBSD project.

All the BSDs have the cohesive feel that comes only from the kernel, userland, and documentation being written by the same people, but they choice of which to use is a matter of personal taste. On a low-volume server, the security and ease of use of OpenBSD can be attractive. On a laptop, the hardware support of FreeBSD can be more attractive. On anything else, NetBSD may be the only choice, and on other hardware, the ease of package management and the lightweight design might make it a better choice. Code is frequently shared between the systems, so a feature you like in one is likely to eventually make its way into the other two.