Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Why OpenBSD?
The GPL is an obvious concern for hardware developers, but TiVo has shown quite conclusively that the second version of the GPL has no teeth when it comes to preventing locked-down devices. So what are the advantages of OpenBSD on an ARM platform? Here's Dale's response to that question:
Size and security are the first things to jump to mind. The OpenBSD kernel with all drivers (including a bunch of USB drivers) is under 3MB. A normal Linux kernel, not counting the loadable drivers, for nearly everything is over 3.5MB. All of the standard OpenBSD security features are present except one. The Non-eXecute control of (W^X) was not possible to support on older arm processors. However, ARM has added this feature to newer (ARMv6/ARMv7) processors, so when OpenBSD supports the Cortex-A8 based systems, this will be present.
These are important things to consider. A typical handheld system uses a package-on-package (PoP) configuration to stack the SoC, some flash, and some RAM on top of each other on the system board. This arrangement gives a fairly limited amount of both storage space and RAM, and extra expansion requires running extra traces on the board, which increases the cost a lot. OpenBSD can easily fit into this space without compromises. A lot of embedded Linux systems are still using 2.4- or even 2.2-series kernels because of their smaller footprint, and this makes porting software to them a lot harder.
The security aspect is even more relevant to a portable device than to a desktop. A desktop typically lives behind a firewall and only has direct access to a (relatively) trusted network. By contrast, a handheld moves around a lot and routinely connects to new, untrusted access points. I asked Dale how ARM stacked up against other architectures from a security standpoint for OpenBSD:
With the addition of the NX (No-eXecute) bit in recent ARM cores, the ARM is now on par with other chips, security-wise. ARM also has some new security features to allow virtualization or running of "insecure operating systems" on the hardware; however, proper use of those features when running OpenBSD has not been identified.
The virtualization features are most interesting for devices like a mobile phone, where you may want to isolate some less-trusted code completely from things like the radio (which could cost you money if used to make calls), or simply restrict the amount of processor time that something gets, in order to preserve battery life. Most interesting, particularly in light of Adobe's recent push to include ARM CPUs in televisions, is the potential mobility provided by ARM virtualization. If you can keep your working environment in a pocket computer and then migrate it to an HD-TV when you get home, the possibilities are very exciting.
I've done a little development on embedded Linux devices, and my major complaint is that Linux completely fails at something an operating system is expected to do: preventing developers from having to know about the underlying hardware. Things like power management—and even simple things like retrieving the total amount of physical memory—have entirely different interfaces on different architectures under Linux, whereas they're exactly the same on PowerPC OpenBSD and on x86. I asked Dale if this was also the case on ARM:
On the Zaurus, the interface to sleep and change processor speeds is effectively the same as on i386/AMD64. The only tweak that Zaurus has that's different is an extra interface to specify the hardware maximum speed. Sharp shipped the Zaurus running at 419 MHz; however, the chip can technically run at 512 MHz. An extra interface was added to allow this to be tweaked by people willing to risk their Zaurus.
As a user and a developer, I think this capability makes OpenBSD a very attractive platform for mobile devices. If you know how to use it on one architecture, then you know how to use it on any architecture. The interfaces are exactly the same. A further benefit comes in lowering development costs. If you write your code on OpenBSD on the desktop, and you don't use any inline assembly (or you provide fallback versions), and you don't use endian or alignment-specific tricks, you can be sure that your code will work on any other OpenBSD platform. Sadly, this isn't always the case for Linux.