An Interview with OpenBSD's Marc Espieby Federico Biancuzzi
Editor's Note: As with FreeBSD's ports and NetBSD's packages, OpenBSD's ports system is a compelling reason to use the system. Its designers and maintainers are, too often, unsung heroes. That's one reason Federico Biancuzzi sat down to interview OpenBSD's Marc Espie. Along the way, they discussed security, licensing, and future plans for the system.
Federico Biancuzzi: Can you give us a short introduction to yourself and your role as open source developer?
Marc Espie: Like most OpenBSD developers, I am very interested in the stability and robustness and security of the whole system. Which means that I do a lot of development outside of my own area: see bug, fix bug. It's as simple as that.
That said, as far as OpenBSD is concerned, I'm the main person responsible for a few main areas:
- the maestro2 driver
- the ports infrastructure
pkg_*tools (especially in current).
And I'm one of the guys who works on
binutils on a continuing basis.
FB: After three months since the release of OpenBSD 3.4 the errata page already contains 11 patches. Most of them fixes kernel bugs. Do you think that in the future we could see more bugs in the kernel than in userland?
ME: I don't have any opinion. It's hard to predict the future, especially where bugs are concerned.
FB: Is this because of a lack of kernel developers? This could explain why someone claimed on full-disclosure that searching for "XXX" and/or "FIXME" strings in obsd kernel is a guaranteed way to locate a ring 0 vulnerability.
ME: This is a publicity stunt. Those kind of childish comments, made by people who don't even give their full name, never cease to amuse me.
If it were that easy to find and exploit vulnerabilities in OpenBSD, it would happen more often.
We could use more developers. There are things we currently do not do because we don't have the manpower for them. There's a scarce pool of talented developers, though. If those wannabe-hackers made a real try at improving our kernel source, that would be incredibly more useful than jibes of bugtraq. Of course, writing good kernel code (or userland code, for that matter) is much harder...
FB: A lot of work has been done removing unsafe string functions. What other activities are part of proactive source-auditing?
ME: Evangelism. If we remove unsafe string functions and other projects add them back, it's like Sisyphus' story. We have to rewrite the same patches again and again when we import some external software.
This is very important and central to OpenBSD: we deal with Unix programming. We're not in that to invent our own little interfaces that NOBODY else in the world has. We're in that to do Safe Unix programming, and introduce a few new techniques when they are necessary.
Evolve the OS, not Revolutionize it. This is in violent contrast to Linux.
We have had a lot of success explaining the issues and getting a lot of
people to switch from
Weirdly enough, the Linux people are about the only major group of people
that has constantly stayed deaf to these arguments. The chief opponent to
glibc is most certainly Ulrich Drepper, who argues that
good programmers don't need
strlcpy, since they don't make
mistakes while copying strings. This is a very mystifying point of view, since
bugtraq daily proves that a lot of Linux and free software programmers are not
that bright, and need all the help they can get.
(Considering the shining, flaming personality of Drepper, and the fact that he is always Right, this is not that surprising, though).
That said, the source audit is work never finished. It's more a question of process than of a specific bug being hunted. The situation goes like this:
- Someone finds a problem with a piece of software.
- Someone fixes the bug, without arguing whether this is exploitable or not.
- Someone generalizes the bug issue as best as he can (a lot of bugs are simple API issues, where a programmer did not understand a specific API).
- Some people look all over the source tree to fix that specific issue.
- Some people try to find out whether the documentation ought to be amended to warn against this specific problem.
- Some people try to find out whether it's possible to augment the compiler to warn against this specific problem and some other problems.
- Some people run the new checker against the source, find problems that ought to be fixed, and fix them.
- Some people try to find out whether the interface is ill-advised, and whether it's possible to get a better interface that will lead to less buggy programs.
FB: Could you talk about the new static bounds checker?
ME: The static bounds checker is mostly the work of Anil Madhavapeddy.
It was an idea of mine originally that he took much further than my idle thinking. My original remark was that code, such as:
char buffer[BUFSIZE]; ... read(fd, buffer, sizeof(buffer));
char *buffer = malloc(BUFSIZE); ... read(fd, buffer, sizeof(buffer));
At some step during development, this has become code that is, of course, wrong, and can often stay uncovered for months or years (if it's error-recovery code that doesn't get invoked very often, for instance).
Anil took it one step further and introduced an extension attribute to gcc:
bounded, that can tie two function parameters, so that you can say, "Here is the buffer and the corresponding size, try to check that it fits."
With a few small changes to gcc, and with declaring that read is such a function, gcc is now able to detect erroneous code, such as:
char buffer[BUFSIZE]; ... read(fd, buffer, BUFSIZE * 2);
Among the same lines, we also added a sentinel checker that can verify that
varargs functions such as
execl(cmd, arg1, arg2, NULL) are indeed
null-terminated (when the arguments are constant), a non-null checker, that
verifies that a parameter cannot be a NULL pointer (to allow distinction
between functions such as
err(3), which takes a format string that
can be NULL, and the standard library
printf(3), which takes a
format string that can NOT be NULL, and some other extra static checks.
The idea is that lots of interfaces in the systems have some extra conditions that are easy to enforce by the compiler, provided we add the correct annotations.
This is just an extension of the default behavior of gcc that does already
some similar magic for
FB: Could you talk about ProPolice and random loading libraries?
ME: ProPolice is a gcc extension developed by Hiroaki Etoh, from IBM, based on older concepts such as StackGuard. ProPolice makes several advances compared to StackGuard:
- It's reasonably portable. It works on most processors.
- It's efficient. It knows enough about the code to add its checks only where they're needed.
- It's more complete than StackGuard. It can reorder variable affectations to make sure overflowable buffers are at the end.
So then, what is ProPolice, and what does it do?
When you have a buffer allocated on the stack, pirates may try to overflow that buffer to change values beyond it and modify the behavior of the running program.
During compilation, ProPolice detects such buffers, and adds code that inserts a so-called "canary" beyond the end of the buffer (the canary image is a mining analogy. In olden times, miners used to get under the earth with a small bird in a cage. As long as the bird was singing, the air was not foul.), and checks that the canary is still alive and well at various moments.
Thus, ProPolice detects buffer overflows on the stack, and terminates the program early. It is useful as a prevention device, because one can get early warning of potential buffer overflows in programs, and fix the bug at the source, and also as a warning system that someone might be trying to enter your system.
Integrating ProPolice in OpenBSD has been hard work. ProPolice has found tons of bugs in various programs that shipped with the system. It's also been the first real-scale test of ProPolice itself. With a lot of hard work from Hiroaki Etoh and Miod Vallat (and Peter Valchev and Christian Weisgerber...). ProPolice itself modifies gcc a wee little bit. But, like most programs of its size, gcc itself is buggy, partly due to its gigantic design that is not quite sane in places. In a typical release of gcc, you don't see the bugs, because the corresponding code paths are never taken. Add ProPolice, and suddenly you're sending gcc through some dark venues that have seen less attention, and all of a sudden you are fixing actual, genuine bugs in gcc.
Now, if you pay attention, you'll realize that doing the same work for gcc 3.x [for] ProPolice is going to be necessary. Hopefully, at some point in the future, we'll get enough attention from the Free Software Foundation that ProPolice is going to be a standard part of gcc, and hence become as well or little tested as gcc proper...
FB: What is the plan for gcc3 introduction?
ME: gcc3 sets a big challenge, because it's sooo much slower than 2.95, compile-time wise. This is a big contending controversial issue with the Free
Software Foundation. Basically, gcc3 puts a lot of nails in the coffins of
elderly, slower architecture. One possible route (like NetBSD) would be to
cross-compile those architectures, which will help kill them. A full build is a
very good test suite for kernel behavior -- more bugs in
been found and fixed by Theo de Raadt, Art Grabowski, Miod Vallat, and
similar-minded people by making a release on a slow machine than by letting the
machine just sit there and act as a firewall with a cross-compiled system.
Another route is to use gcc3 on architectures that really require it, or don't
mind the slowdown, and keep gcc 2.95 for other architectures.
There is some faint hope that maybe gcc 3.4 might almost be as fast as gcc 2.95 is...
That said, all of source compiles with gcc3, arches under development, such as arm and x86-64, are based upon gcc3, and I don't know yet whether sparc64 will ship a gcc2 release or a gcc3 release.
As usual, the project goes slowly and carefully.
Enough issues were fixed so that you could compile a whole system and run it with gcc3. That's what my laptop is running, in fact.
Pages: 1, 2