Security in Your Pocket: OpenBSD on ARM

• By David Chisnall
• Sep 11, 2009
• Article is provided courtesy of Prentice Hall

From the author of
Definitive Guide to the Xen Hypervisor, The

When you think about OpenBSD, if you think about OpenBSD at all, you probably think of firewalls and routers. Maybe servers, and possibly desktops (but probably not). Recent versions have nice sound and 3D support, so desktop use isn't too unlikely, but one thing you probably don't think of is handheld systems.

The handheld operating system market is largely owned by Symbian, although its market share has been eroding over the last few years. Linux is starting to make inroads, and some people still use WinCE devices (developers for the platform tell me that naming it "wince" was more accurate than most Microsoft product names). Given that Symbian now has a POSIX layer and Linux has always aimed toward POSIX compliance, it's starting to look as if handhelds may end up running a lot of the same software as desktops.

The First Ports

The initial port of OpenBSD was funded by DARPA; Dale Rahn, who was employed by the DARPA grant to OpenBSD, and who had formerly worked for Motorola on ARM simulations, received the donation of a desktop ARM system. After this initial port, he returned to Motorola. At the time, a number of Motorola's customers were interested in a UNIX-like system for ARM chips, but didn't want to use GPL'd code in their products. Dale was hired to work on a BSD-licensed system for these customers.

One of the first handheld platforms to excite the Free Software community was the Sharp Zaurus series. These clamshell machines featured a 416 MHz Intel ARM CPU and 64MB of RAM. Most importantly, they shipped with Linux. At the time they were introduced, flash was still very expensive, so instead they came with a microdrive—a tiny mechanical disk.

Running Linux meant that there was already support from a toolchain capable of building a similar system. In addition, most of the hardware was well documented. In 2005, a few OpenBSD developers got hold of Zaurus systems and began a port of their operating system. The Zaurus used the same system-on-chip (SoC) module as the mobile phones Dale had been working to support at Motorola.

A few of the OpenBSD developers still use the Zaurus, but it's starting to look a bit dated. The screen is quite small, and the processor is a lot slower than a modern ARM system. I asked Dale if he had his eye on any more-recent devices:

We had started to look into the Nokia N800; however, there wasn't quite enough information available to get the port started properly at the time.

Work was started on the Openmoko FreeRunner and Gumstix (PXA270) at h2k8 last November, but those projects have stalled since I have had little free time lately. At this point, both of those hardware [lines] have been discontinued, so it is unclear how far those ports will proceed.

The situation isn't quite as bad as it seems, though. A lot of devices are starting to appear based around the Cortex-A8, with Texas Instruments' OMAP3 series being the most popular, and Motorola's i.MX5 is a newer entrant aimed at the netbook market. Dale continued:

Upcoming devices which look interesting include Beagle Board and Gumstix Overo. I have temporary access to a Beagle Board, but to support it properly [I] would need one or two for development and regression testing.

A number of companies have announced that they're planning to produce netbooks based around ARM cores, and companies such as Dell are now shipping hybrid systems that have both x86 and ARM CPUs. Dale mentioned his interest in the Latitude ON feature in these systems, which uses an OMAP3 core in Dell laptops for instant-on support. By keeping the home directories on a separate partition, it would be possible to have OpenBSD/ARM and OpenBSD/x86 installed on such a machine, using one when on battery and the other when on main power.

OpenBSD gained a lot of clean hardware abstraction from NetBSD, and has maintained this since it was forked. All code in the base system is expected to be tested on several architectures, including i386 and SPARC64, which provide almost diametrically opposed sets of constraints. I asked Dale how much time it took to get the initial Zaurus port working:

Most of the work was done in a couple of months. I did the bulk of the work, with dlg@ doing most of the USB host, miod@ most of the display driver work, [and] uwe@ did most of the apm/suspend/cpu-speed changes.

This was a port from the Cats platform, a desktop ARM system based around an evaluation board (and generally loathed by most developers), but it required new drivers to be written for a lot of the hardware. I asked Dale how much effort was needed to add support for a new SoC:

Depends on if the family of chips is supported or not. Typically a family of chips will have the same (or very similar) timers and interrupt controllers. So these must be rewritten for each family; however, for a new version of the family of chips, it is just a minor tweak or reused.

Most platforms can be up and running on uart, with the basic devices (uart, tick timer, interrupt controller) running in a few days to a few weeks. However, supporting additional pieces, USB (host and client), SD, CF, gpio keyboards, audio can take quite a bit longer. It definitely helps if hardware is available to other developers for them to work on their different areas of expertise. A bigger problem exists when the processor core isn't supported; e.g., Cortex-A8 removed one of the features in the mmu that was being used, so the physical map code needs work to function with the new changes, W^X support can be added at that time.

Unlike x86, which has always aimed to be backwardly compatible (even a new, 64-bit, x86 chip can still boot MS-DOS 1.0), each new ARM instruction set revision typically includes a new set of privileged-mode instructions, and therefore needs extra support, as do all of the other devices integrated into the SoC. Fortunately, a lot of devices outside of the SoC are not attached via standard interfaces such as compact flash or USB ports. Once OpenBSD has a working device driver for the bus, these can all run using existing drivers. If a USB webcam works on OpenBSD, for example, it will work on any OpenBSD platform with a USB driver.