Kernel Trap Interview with Theo de Raadt

An anonymous reader writes "KernelTrap has an insightful interview with Theo de Raadt, creator of OpenBSD. The wide-ranging interview focuses first on the past few years of OpenBSD development, then moves on to the recently released OpenBSD 3.9. De Raadt talks about how binary blobs threaten free software, and how OpenBSD developers work to reverse engineer them. He also talks about the future of OpenBSD, his views on Linux, and why developing truly free software is so important to him."

Financing?

[AltGrendel]

...I swear I will never get over how incredibly much money a University acting as a middle man between DARPA and us can bleed the flow of financing.

Any idea who he's refering to?

Re:FCC Rules

[Homology]

See, here's the thing...the people he needs to convince here are the hardware manufacturers. You aren't going to get them to release open drivers by suggesting that the FCC should "go after" them.

You did not really read that article, did you? OpenBSD wants hardware documentation, and besides, why should I as an EU citizen care about FCC regulations?

Re:Financing?

[Anonymous Coward]

All of them. In grant financing, the institution will often take a percentage of the gross, as large as 48%, or more in some cases. It's justified under a multitude reasons, e.g., management, common facilities, name, reputation, goodwill, etc.

Sometimes these funds get funneled back through deans to dept. chairs and, yes, the even PI as a salary bonus, thereby allowing them to write a larger salary number in the next grant.

I'm not saying it's right but that is the way it is.

Re:Theo

[MerlynEmrys67]

Here is the problem with Theo. He is smart and opinionated. Having these two things in common make him a very difficult person to get along with if you are either Smart, but hold a different opinion because you come from a different set of assumptions - but especially if you are NOT smart and opinionated.

I have had discussions with Theo about trying to get my current employer (at the time) to open up documentation so OpenBSD could write drivers for our hardware. Lets just say I failed (Sorry Theo - I really tried, to the point that my annual raise was affected by it). However I found Theo to be very supportive and personally agreeable to me - I assume he realized I was trying to help and doing the best I could.

I can imagine people that are fighting against things he is trying to do could see him in a negative light - but again... I see the same kinds of things said about all of the great ones.

We don't buy hardware that OpenBSD doesn't support

[linuxbaby]

Though we only use OpenBSD on a few of our servers (we have about 150 servers) - we NEVER buy hardware that OpenBSD doesn't support, because to us that's a good test of whether this hardware is going to last or not.

If a hardware company is so proprietary or secretive or locked-down that OpenBSD can't (or chooses not to) support it, I don't believe that company will last in the long run.

Re:NDAs are a big problem?

[drinkypoo]

Theo apparently feels (as I do) that the more we support vendors who refuse to just open up their specs, the less vendors will open them up. If Linux is taking over the server market (it is) and they need to open their device specs up to have them supported (they don't, if people will go NDA) then more companies will open up their specs so that they can be supported by linux - because companies like to minimize the variety of hardware in their organization for support reasons, and they are more likely to spec a single NIC that works in all situations (if available) than spec two different ones, one for Linux, and one for Windoze.

As long as people develop drivers for these products through reverse engineering or NDA, then these manufacturers will have no reason to release specs.

Re:NDAs are a big problem?

[J.R. Random]

The very fact that an NDA is used means that the manufacture knows that the writer of the driver needs facts that can not be determined by looking at the source of the driver itself. Typically this involves the use of various magic constants that must be loaded into device registers at appropriate times. The manufacturer knows what the magic constants mean. Hopefully the writer of the driver does too. But nobody else does, and the author of the device driver can't tell them. So if there's a bug (maybe because the magic constant wasn't quite the right one to use in certain circumstances) there's no way for another person to fix it. Likewise if there's a desire to expand the functionality of the driver there is again no way for a third party to know what the magic constants should be.

Re:So petulant and arrogant.

[akpoff]

When Theo or the other OpenBSD folks complain about projects taking without giving they know what they're talking about. Theo knows for a fact whether Sun or other companies have donated to the OpenBSD project.

If you were minded to you could find out for yourself what Theo has contributed. Scan the source tree of just about any project the OpenBSD team ships and hunt for openbsd.org. If by chance you don't find anything then search again for "De Raadt" or some of the other developers' names. More likely than not you'll find code contributions.

If that's not enough, look at the number of companies Theo and his team and users have lobbied to release documentation thus helping all projects. Note also the Free Software Foundation and others respect and have honored Theo's work and contributions. In 2004 the Free Software Foundation presented Theo with the FSF Software award [fsf.org]

For recognition as founder and project leader of the OpenBSD and OpenSSH projects, Theo de Raadt's work has also led to significant contributions to other BSD distributions and GNU/Linux. Of particular note is Theo's work on OpenSSH. Theo's leadership of OpenBSD, his selfless commitment to Free Software and his advancement of network security, were cited by this year's award committee.

Try google -- it's your friend when you have these kinds of questions.

Re:Theo

[laffer1]

You got to be kidding me. Theo's got a serious attitude problem. He told me if he ever met me, he'd kick my ass because I didn't know who he was when I first got into FREEBSD! I had a confrontation with him on freebsd-questions early on. Granted I didn't know what the hell i was talking about at the time, but he went on another bsd's mailing list and insulted their users. Intelligence has nothing to do with knowing about a specific thing. I wasn't up on bsd history then. I've met many smart people doing IT work that couldn't read their email. I don't think they are automatically stupid as a result. (Doctors, lawyers, etc)

If you need further proof of Theo's attitude, look up the history behind him leaving NetBSD. You'll find that he co-founded NetBSD, had a fight with the rest of the core team and ended up fork()ing OpenBSD. I don't think he was completely in the wrong, but he didn't handle it very well either. I'm sure there was more too it than that. I don't blame theo for controlling OpenBSD the way he does. He got burned once and Linus has a firm grip on the Linux kernel as well. Even FreeBSD has a rough track record with developers, look at Matt Dillon's situation and his DragonFly fork.

I think most open source developers can be real dick heads. We are often opinionated and think we are always right. We also love attention.. hell its free software, what else will we get out of it. (except the people who write books to profit...) I'm including myself in this group. It takes arrogance to create/fork an operating system or develop a programming language. (Larry Wall, Theo, Linus, etc)

OpenBSD code auditing?

[raw-sewage]

TFA had a typical comment from Theo or any OpenBSD core team member: "As we become aware of more problems in the C language, we are trying to be very agressive to make the code cleaner. Just the standard OpenBSD proactive auditing process."

My question is this: what is the "standard OpenBSD proactive auditing process"? Before, I've lightly asked about this on the misc@ mailing list, but the answers weren't very helpful, generally paraphrased as (1) experience or (2) study the CVS diffs.

Well... that's nice, but I'd like to have a more straightforward "beginner's approach", something a little more accessible. I agree that only experience will make you a truly great secure and correct coder, but it would be nice to have a book that explained (and gave examples) of the kinds of things that the OpenBSD developers routinely look for in their code audits.

Put another way, I feel I have a good understanding of the fundamentals of secure C programming: generally prefer strncpy() (or strlcpy()) to strcpy(), know when to use memmove() or memcpy(), always check input parameters to make sure they are within the defined boundaries of the function, etc... but surely there's more than just these well-known general rules of thumb, right? It would be nice if core OpenBSD developers could have their secure C programming expertise dumped into a book!