In a recent email, OpenBSD creator Theo de Raadt [interview] described a number of modifications to how OpenBSD allocates memory. In preparation for the upcoming 3.8 release, Theo asked for people to beta test -current as the recent modifications will likely cause instabilities in many applications. One of the modifications was to make the mmap system call return a random memory address, as well ensuring "that two objects are not mapped next to each other; in effect, this creates unallocated memory which we call a 'guard page'." Another was to update the malloc function to use mmap to obtain memory. Finally, the free function was updated to immediately return memory to the kernel and un-allocate it from the calling process. Additional changes were also made, but unlike these three the additional changes are not enabled by default as they are "too dangerous for normal software or cause too much of a slowdown".

Theo points out that these changes have a couple of significant impacts. He explains that for over a decade efforts have been made to find and fix buffer overflows, and more recently bugs have been found in which software is reading before the start of a buffer, or beyond the end of the buffer. With these recent memory allocation changes, such an attempt will cause the application to coredump with a SIGSEGV signal. Additionally, now that memory is unmapped as soon as it is freed, any attempt to access freed memory will also cause the application to coredump with a SIGSEGV signal. He explained, "we expect that our malloc will find more bugs in software, and this might hurt our user community in the short term. We know that what this new malloc is doing is perfectly legal, but that realistically some open source software is of such low quality that it is just not ready for these things to happen." Hence the request for beta testers to help track down these misbehaving applications. Theo concluded, "instead of saying that OpenBSD is busted in this regard, please realize that the software which is crashing is showing how shoddily it was written. Then help us fix it. For everyone.. not just OpenBSD users."

Bob Beck is an OpenBSD developer from Edmonton in Canada. He's one of around 60 OpenBSD developers currently working in an undisclosed hotel somewhere in downtown Calgary at the 2005 OpenBSD hackathon [story]. Bob was involved in setting up the infrastructure [story], and was responsible for the annual barbecue at OpenBSD creator Theo de Raadt [interview]'s house [story]. Following these two days of effort that helped to make the hackathon possible, he finally sat down to work on spamd and catch up on email. One of the emails in his inbox caught his attention, leading to a day's effort about which he notes, "some Days end up far far far from where they start."

In the following article, Bob provides a first-person account of tracking down what began simply as a RAID performance issue, but ultimately turned out to be a problem with the idle loop that when fixed resulted in an impressive performance boost. Bob noted, "the idle loop is where the kernel spins when there is no work to do in userland, because of this, it's also where we catch and service many of our interrupts from drivers that may queue work to the device and then tsleep waiting for an interrupt from the card saying the work is done." Bob went on to explain that prior to today's fix, interrupts were handled appropriately when there was userland work happening, but not when there was nothing happening in userland and the kernel was simply waiting for device input/output. Read on for Bob's full account of the day, leading up to the discovery of the problem and the implementation of the fix, including performance numbers.

OpenBSD creator Theo de Raadt [interview] announced that Intel has refused his request to permit that the firmware for their wireless chipsets be made freely distributable. He explains, "I had asked for free terms under which we (and Linux, anyone) can redistribute the firmwares for their wireless chipsets. Without these firmware files included in OpenBSD, users must go do some click-through license at some web site to get at the files. Without those files, these devices are just bits of metal, plastic, and sand." Intel is one of several companies being approached by OpenBSD in a coordinated effort to try and free up the availability of firmware for wireless chipsets [story]. Several vendors including Symbol, Zydas, and Atmel have responded favorably, licensing their firmwares so that they can be distributed freely with OpenBSD.

As to the reason Intel refused to update their licensing, Theo explained that they referenced obligations to outside parties. Further clarification as to exactly what that means was not provided by the company. Theo went on to note that though this concludes his dealings with Intel, users are still encouraged to contact them and express their concern for this policy, "maybe they will listen to enough customers, or they will learn to not make this mistake again with future chipsets. I for one have already decided that I will never recommend an Intel product to anyone ever if there is choice. (There is almost always choice)."

Ryan McBride [interview] explained on the OpenBSD -misc mailing list, "we'd like to support the Texas Instruments ACX100 802.11b wireless chipset (DLink DWL-520+, DWL-650+, and others), but we can't include a working driver without the firmware binary blob, which is available but has a restrictive license. We have tried to contact TI, through all the channels available to us. They have not even replied to our mail." Ryan goes on to request that the OpenBSD community help by expressing their concerns to the company as consumers, including a copy of a letter he sent to a list of contacts within the Texas Instruments wireless department.

OpenBSD creator Theo de Raadt [interview] pointed out that this same tactic has been successful many times, specifically mentioning about six years ago when it was employed to obtain documentation for Adaptec's scsi chips. He goes on to explain:

"In this case, we are not asking TI for documentation for their boards. A driver already exists. I believe it was reverse engineered by some Linux people, and BSD work is in progress. We just want to discuss with TI what licensing changes might be possible so that the firmware for their cards can be included in Open Source operating system releases. Having to install a firmware file only found on a CDROM sold with the card after install is crazy."

OpenBSD [forum] creator Theo de Raadt [interview] recently announced that support for the SGI O2 architecture was soon going to be imported, primarily in an effort to hunt down and fix bugs in the OpenBSD codebase. He explains:

"Why add a new architecture? SGI's mips machines are dead, aren't they? Well our expierence has been that every architecture we add has helped us find bugs in shared code that affects other architectures. [...] Some very scary and major bugs have been dredged out almost automatically. In some cases, the effort is not worthwhile. In this case, I judge it to be valuable. In particular, the SGI developer will probably peek out quite a few busdma bugs, which will affect driver support on any busdma architecture."

The busdma APIs were originally developed on NetBSD [forum], aka bus_dma, to help reduce the dependancy of device drivers on platform specific code, therby increasing portability. These APIs were ported to other BSDs such as OpenBSD and FreeBSD [forum] several years ago.

A little over a year ago, prior to the release of OpenBSD 3.2 [story], NTP support was removed from the OpenBSD kernel due to a "misplaced modifier" in the software's license [story]. At the time, when urged to rethink this change and to ship NTP anyway, OpenBSD creator Theo de Raadt [interview] explained, "we cannot. The code is not free enough."

It was announced today on the misc@ OpenBSD mailing list that a new replacement written from scratch has now been merged into the base OpenBSD installation, part of the upcoming OpenBSD 3.6. Henning Brauer noted that this completely new implementation of the ntpd daemon was designed with security in mind, "of course it is privilege seperated, chroot()ed etc ;)" Christian Weisgerber went on to explain:

"The new ntpd in base is very, well, basic so far. It can (1) distribute the local system time to clients and (2) adjust the local time to track one or more servers. It doesn't support xntpd's broadcast/ multicast/ anycast or authentication or plethora of other features, and you can't hook up your external reference (atomic, GPS) clock to it--although work on the latter is underway. It's far from a complete replacement of xntpd, and I don't think that's a goal, but it already does all most NTP users care about."

With the conclusion of the recent OpenBSD 2004 Hackathon, symmetrical multiprocessor (smp) support was announced for the amd64 architecture. Artur Grabowski announced the commit on the misc@ mailing list earlier this weekend:

"I just comitted support for SMP on amd64. Most of it is based on work done in NetBSD but we had to fight a lot [to] fix the last few bugs, especially related to non-executable mappings and some interrupt routing issues."

Earlier this month OpenBSD SMP support was also merged for the i386 architecture. OpenBSD developers encourage anyone with the necessary hardware to test SMP support on either of these platforms to send your dmesg so they are able to track on which hardware it works and on which hardware it doesn't work. The OpenBSD project is currently looking for donations of SMP amd64 hardware to allow them to continue to test and support it.

A recent thread on the OpenBSD project's misc@ mailing list discussed why OpenBSD has chosen to stick to a purely monolithic kernel, instead of trying to optimize performance by using kernel modules. As described in the OpenBSD FAQ, the OpenBSD team only supports the GENERIC kernel that is provided with the distribution. Numerous reasons were provided, including security, the ability to fully test, and simplicity.

In the recent discussion, Ben Goren explained, "Back in the day, I wasted far more time screwing around with compiling Linux kernels--and the modules were the worst part--than I ever saved by even the more aggressive performance boost. And those loadable modules didn't give me anything in convenience, either; quite the contrary. Ethernet modules refused to load, and more...." OpenBSD creator Theo de Raadt [interview] agreed, replying, "don't worry -- nothing is going to change. Simple is powerful." However, Theo acknowledged that a seperate kernel will likely be provided for SMP support at least to begin with, "even minor uses of locks slow performance a lot, as everyone has noticed by now.."

Theo de Raadt [interview] announced that StackGhost has been enabled on the OpenBSD/sparc architecture. Theo explains:

"The above paper by Mike Frantzen describes a ProPolice-like security technology for protecting the stack on sparc (v6 v7 v8) machines. While ProPolice is a compiler modification (ie. the compiler produces "stack checking" code) -- StackGhost is a very small modification to the register window spill/fill handlers.. used to gain a similar security benefit, this is all possible because of the particular (curious, strange, weird) method of same-stack register window saving used by the sparc calling convention."

Essentially, StackGhost provides return-address modification protection (frequently used in buffer overflow attacks), at basically no cost. The original code was written several years ago for OpenBSD 2.8 by Mike Frantzen, but only enabled now thanks to the merging of gdb 6.1 and some code written by Mark Kettenis. The paper linked above describes some performance costs associated with this protection functionality, but these costs have been nearly entirely optimized away by Mike and Theo since the paper was written.

Following the recent excitement over a potentional vulnerability in TCP [story], Cisco's "Worldwide Patent Counsel", Robert Barr, has let it be known that they have pending patent applications for one or more of the IETF recommendations for improving TCP's security. Robert says:

"If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will be able to obtain a license from Cisco to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard."

In response, OpenBSD creator Theo de Raadt [interview] said, "The Cisco/IETF recommendations contain numerous problems and issues. They should not be followed. We have better fixes in OpenBSD. Other vendors should be looking at these." For example, as mentioned in our earlier article about TCP reset attacks [story], with the IETF's/Cisco's recommendations in place it would be possible for an attacker to use one host to potentially flood another. A full discussion of OpenBSD's alternative solutions will be explored in our upcoming article, "Understanding TCP Reset Attacks, Part II".

Ryan McBride recently announced that he has imported into -current support for CARP, OpenBSD's new Common Address Redundancy Protocol. He explains:

"This protocol allows multiple hosts on the same local network to share a set of IP addresses among them. Some of the functionality it provides is similar to VRRP, although CARP differs in some significant aspects: CARP has been designed to provide greater security and be protocol independent (so we can support both IPv4 and IPv6). Finally, CARP allows for some level of load balancing in addition to its high-availability functionality."

CARP is still under development, and won't be found in the upcoming November release of OpenBSD 3.4 [story]. Instead, it will be a feature to look forward to in OpenBSD 3.5. Read on for Ryan's full announcement email detailing the new protocol, as well as a few other short threads related to the recent import.

Mike Frantzen recently committed OS fingerprinting capabilities to PF, OpenBSD's stateful packet filter, based on Michal Zalewski's p0f (passive OS fingerprinting) code. The functionality was also added to tcpdump. From the p0f README:

"The passive OS fingerprinting technique is based on information coming from a remote host when it tries to establish a connection to your system. Captured packet parameters contain enough information to identify the remote OS. In contrast to active scanners such as nmap and queSO, p0f does this without sending anything to the remote host."

Mike points out that it is very easy to spoof a TCP stack to make one OS appear as if it's really another, so this new functionality is not a security feature. Instead, it's intended as a policy feature... For Mike's announcement email which includes a few quick examples of how this functionality might be used, read on.

PF creator Daniel Hartmeier [interview] posted a summary of recent work accomplished on the PF packet filter at this year's OpenBSD Hackathon, c2k3. The event got a lot of coverage recently when the U.S. Defense Advanced Research Projects Agency (DARPA) abruptly pulled funding and canceled hotel bill payments, apparently attempting to prevent the event from happening due to (and I quote) "the evolving threat posed by increasingly capable nation-states." Thanks to OpenBSD user donations, the largest OpenBSD Hackathon to date proceeded as planned.

Those interested can read on to find OpenBSD creator Theo de Raadt's [interview] May 10'th announcement of the hackathon's start, and Daniel's May 22'nd summary of the PF related work. Daniel also points to photos from the event, found online here and mirrored here".

It was recently proposed on the misc OpenBSD mailing list that support for the Network Time Protocol (NTP) should be added to the "base" package. Ken Lalonde suggested, "Maintaining accurate time is critical on firewalls, or any secure application. OpenBSD should support this out of the box." OpenBSD Founder Theo de Raadt [interview] quickly replied, "We cannot. The code is not free enough."

The OpenBSD project is known for strictly enforcing its policy that OpenBSD remain completely free. The specific clause in the NTP license preventing it from future inclusion reads, "Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all". Theo explains the problem:

"This is a misplaced modifier that has a 2nd meaning -- that it cannot be sold. I've talked to lawyers. It's a real problem, and they say they won't fix it."

NTP support was actually removed from the kernel prior to the release of OpenBSD 3.2, however as an oversight, even the current OpenBSD 3.3 [story] release still includes the source for ntp on the CD in the ports directory. Theo explained that due to this license incompatibility, NTP will no longer be included on future CDs (though it can still be distributed via FTP, as there is no charge for this service). The OpenBSD CD does include rdate, which allows one to synchronize with an SNTP/NTP server.

The OpenBSD project has released OpenBSD 3.3 with an impressive array of exciting new features. A complete list of changes can be found here. Todd C.