[ISN] Interview: Theo de Raadt of OpenBSD

InfoSec News isn at c4i.org
Wed Mar 29 03:40:43 EST 2006


By: Manolis Tzanidakis 
March 28, 2006

Theo de Raadt is the project leader for OpenBSD, a Unix-like operating 
system. We spoke with Theo about the upcoming release of OpenBSD, 3.9, 
the financial state of the project, and about companies that profit 
from free software without contributing back.

NewsForge: Hello Theo. Could you tell us a few things about yourself 
and your involvement in the OpenBSD project?

Theo de Raadt: I have been the project leader for OpenBSD now for more 
than 10 years, and along the way I have had some good adventures with 
the developers in the group. We've developed some side projects as 
well, which are heavily used by everyone in the Unix world, such as 

NF: How many developers contribute to OpenBSD at the moment?

TdR: Inside the project, the count has slowly grown. It was 40 in the 
early years, and now it is about 80. Of course, that is just counting 
internal developers. There are many more people on the outside who 
send us bug reports, fixes, or new code contributions. We also are 
able to take pieces of code from other sources if they are 
sufficiently free. But since internal developers have more 
responsibility -- they have really maintained the areas they are in -- 
the people on the outside really have an easier job, and should not 
envy the people on the inside. Instead, they should find a bug, write 
a fix, and send it in. When someone on the outside sends us many 
(good) bug fixes, we invite them to become a developer.

NF: You regularly organize events called hackathons. What exactly is a 

TdR: This is something we started many years ago. A bunch of us would 
fly to one location (typically before or after a conference) and we 
would sit down and code. These events really are about getting tasks 
done; there is very little chatter, as we already know basically what 
needs to be done. They are not meetings, no one presents talks, nor 
are they so-called summits. They are for taking action in the source 
tree, knowing that the guy you need to ask a question of really 
quickly is sitting at a table a meter away.

NF: OpenBSD is considered one of the most secure operating systems 
currently available. What approaches do you take towards security?

TdR: We've had 10 years of nearly fanatical devotion to anything which 
can make OpenBSD more secure. A very important part of that is that we 
have not been afraid to completely overhaul anything even if it breaks 
backward compatibility. Secondly, when we have found a flaw in any 
part of the system we have assumed that the same mistake was made 
elsewhere, and gone on a hunt to fix them all. Thirdly, we have 
developed and incorporated a collection of methods that make software 
flaws very difficult to attack.

The important detail is that in all three of these areas we have not 
only been fanatical, but pretty much first. Other vendors are not 
treating their source code the way we treat ours -- with distrust, 
knowing that we should always actively churn it, so that it can slowly 
evolve into a better state.

Someone on wikipedia has gone through a lot of effort to identify some 
of our security efforts, and there is the Exploit Mitigation 
Techniques paper which I have presented at a number of conferences.

NF: Why should someone use OpenBSD instead of another operating 
system, besides security?

TdR: I don't really take any position of advocacy. People should use 
what they want to, and I am not the right person to say anyone 
"should" do anything. But hey, if someone is adventurous, check it 

NF: A new stable version, 3.9, is about to be released on May 1. A 
complete changelog between 3.8 and 3.9 is available; would you comment 
on some of the new features of this release? Start with G5-based Mac 
support on macppc architecture. How well does it work at the moment? 

TdR: It works on some of the models. For some of the machines we have 
a strange bug in the Serverworks SATA chipset that we have not been 
able to fix yet. There is no documentation for that chipset, of 

NF:Hardware sensors support (ESM, IPMI, IIC) -- a useful feature, 
especially on servers. 

TdR: This has been a significant effort this release. These are three 
major subsystems that provide temperature, voltage, and fan sensor 
data. We have a unified system above that, that takes all this and 
makes it available to a daemon that can alert you when things go 

Regarding specifically the "i2c" subsystem: in the Linux world there 
is the lm-sensors package, which requires all sorts of 
hand-configuration for each specific machine. In OpenBSD, we carefully 
probe for the devices, and it should just work, on every single PC, 
without any configuration. Thus, pretty much every OpenBSD 3.9 machine 
will have some sort of sensor now.

We have more work to do now that 3.9 is released, since the sensor 
daemon is a bit weak for reporting events. We want to make it 

NF: The new ftp-proxy -- why write a new FTP proxy daemon when the 
previous one worked fine? 

TdR: FTP is a nasty protocol to begin with, and trying to proxy it 
perfectly is a very difficult task. The new daemon just has a better 
design, and IPv6 works as well.

NF: NFE, the Nvidia nForce MCP Ethernet adapter. How did you manage to 
write this driver? Is it reverse-engineered? 

TdR: Nvidia did not give anyone documentation. Instead, they expect 
people to load a gigantic blob of binary code into their kernel, and 
just be happy with that. Some Linux people in Germany 
reverse-engineered the driver years ago, but the rough story I heard 
is that Nvidia asked them to stop, and they did. This just astounds 
me! In any case, Jonathan Gray (who started this effort) asked for 
their help with a few problematic technical details, and they refused. 
I could not believe that, so I asked as well -- and they refused 
again. These are Linux developers, basically placing the community in 
a situation where they have to run a binary blob of unknown code from 
a vendor, instead of sticking to their guns about open source? I must 
admit, I just don't understand some people. They must have much more 
flexibility to their belief systems than I have.

Damien Bergamini joined Jonathan toward the end and got all the bugs 
out of the driver. We are happy to say that it appears to be working 
better than the Nvidia binary blob. It is also significantly smaller, 
and it is very clean source code.

NF: In the past there was a movement in the OpenBSD community to press 
hardware vendors to release documentation about their products 
(Ethernet and wireless network adapters, RAID controllers, etc.) so 
that drivers could be written for OpenBSD or other open source 
projects. Some vendors did release documentation, but others didn't. 
Why do you think vendors do that? They don't want their products to be 
supported on OpenBSD?

TdR: There are always at least a few efforts in the project to get 
more documentation out of vendors. But some vendors are still 
incredibly resistant. We often run into vendors who have signed NDA 
agreements with Linux developers, who will then happily write a Linux 
driver filled with magic numbers, which only one developer in the 
world understands. Having signed the NDA ensured that Linux got a 
working driver, sure, but the internals are indistinguishable from 
magic. It cannot be fixed by anyone else, because it is full of 
secrets. It is a source code version of a blob.

There are many reasons why vendors will not give information out. I 
believe that all their reasons are a lie to the customer. I can get 
nearly complete data books for the parts that are in my car, and I 
should be able to get them for the parts in my computer.

Once in a while we hear from vendors out of the blue, and they offer 
us hardware and software without us having to ask. It is happening 
more -- mostly from Asian hardware manufacturers eager to have their 
hardware supported by all systems. On the other hand, American 
companies in particular are becoming increasingly insular, and 
sometimes we think twice before wasting our time trying to contact 
them. As a result, our support for a few high-end or very new American 
products is lagging, because there just isn't documentation available. 
That is a problem, but it should not be overstated, because 99% of the 
world is buying these Asian products. For instance, Asian 802.11 
vendors accounted for perhaps 1% of the market five years ago, but 
within a year or two the market is likely to be split between Intel 
(because of how they tie their wireless chipset into their laptop 
Centrino brand) and the Asian vendors, such as RAlink and Zydas.

NF: Now that OpenBSD's user base seems to have increased a bit, do you 
have more success convincing vendors to release documentation for 

TdR: We are having more success getting documentation, but I am not 
sure if it is due in any way to our user base size. Part of it might 
be that many more products are coming from Asia (where business sense 
still applies -- the customer gets the documentation he wants). I 
think that the Asian businesses are just being smarter about this. 
When it comes to documentation requests, an Asian company that says no 
is rare. An American company that says yes is rare.

NF: I understand that OpenBSD is financed from CD sales and donations. 
Does this money pay for all the projects needs?

TdR: Our income varies year to year. Donations rise and fall, and so 
do the sales of our products. Meanwhile, our FTP servers just keep 
getting busier.

We have built up some savings to deal with a rainy day, but our basic 
operation is perhaps falling behind slowly, or at least slowing our 
growth. We want to hold more hackathons, since that is where many 
amazing developments come from. If we had more money, we would also 
want to pay the travel expenses of some of the poorer developers, 
since we have some smart developers who are students or live in poorer 
countries. But with the finances we have, it is difficult to justify 
these things now. I want us to do much more, but we are constrained.

Donations make the most difference, since our project does not get 
taxed on them. We have investigated becoming a non-profit 
organization, but the margins and savings really do not make sense for 
our project, especially since most of our donations do not come from 
the country where we operate. Also, there are numerous other 
constraints and rules. So for now we are sticking to clear cash 
donations, without tax receipts.

NF: Lots of hardware vendors use OpenSSH. Have you got anything back 
from them?

TdR: If I add up everything we have ever gotten in exchange for our 
efforts with OpenSSH, it might amount to $1,000. This all came from 
individuals. For our work on OpenSSH, companies using OpenSSH have 
never given us a cent. What about companies that incorporate OpenSSH 
directly into their products, saving themselves millions of dollars? 
Companies such as Cisco, Sun, SGI, HP, IBM, Siemens, a raft of 
medium-sized firewall companies -- we have not received a cent. Or 
from Linux vendors? Not a cent.

Of course we did not set out to create OpenSSH for the money -- we 
purposely made it completely free so that the "telnet infrastructure" 
of the 1980s would die. But it sure is sad that none of these 
companies return even a fraction of value in kind.

If you want to judge any entity particularly harshly, judge Sun. 
Yearly they hold interoperability events, for NFS and other protocols, 
and they include SSH implementation tests as well. Twice we asked them 
to cover the travel and accommodation costs for a developer to come to 
their event, and they refused. Considering that their SunSSH is 
directly based on our code, that is just flat out insulting. Shame on 
you Sun, shame, shame, shame.

I will say it here -- if an OpenSSH hole is found that applies to 
SunSSH, Sun will not be informed. Or maybe that has happened already.


1. "Theo de Raadt" - http://www.theos.com/deraadt/ 
2. "OpenBSD" - http://www.openbsd.org/ 
3. "3.9" - http://www.openbsd.org/39.html 
4. "Someone on wikipedia" - http://en.wikipedia.org/wiki/OpenBSD_security_features 
5. "Exploit Mitigation Techniques" - http://cvs.openbsd.org/papers/ven05-deraadt/index.html 
6. "available" - http://www.openbsd.org/plus39.html 

More information about the ISN mailing list