OpenBSD 3.7: The Wizard of OS

Today the OpenBSD project announced the new 3.7 release. This is the
first release to support newer wireless chipsets, especially for 802.11g,
thanks to a big activism campaign lead by project leader Theo de Raadt. It's
now possible to create a portable access point with a tiny PDA using the Zaurus
port, too. As usual, there are a lot of other big and small changes, such as the
import of Xorg, the jump towards gcc3, and a feature to update your installed
packages automagically. Discover the details behind the scenes in this
interview that Federico Biancuzzi had with several OpenBSD developers.

Many people will probably enjoy this release especially for the
rich set of new Wi-Fi chipsets supported. It took years, but now you support
them with total compliance with your goals and license. Which vendors would
you define as open-source-friendly and which as unsupportive?

Damien Bergamini: Ralink Tech. and Realtek have been very
friendly by providing us documentation for their wireless chipsets. Ralink
Tech. gave us the spec for their RT2500USB 802.11 b/g chipset and about one
week later, we had a working driver (ural) for it, just in time before 3.7 code
freeze. The work on this driver now continues in OpenBSD-current and I'm adding
advanced functionalities like HostAP mode support (the capability for a host to
act as an access point). OpenBSD was the very first operating system to provide
an open source driver for the RT2500USB chipset, and AFAIK it is still the only
one to support this chipset today. I know some Linux users that feel jealous
about this ;)

It is important to show vendors what they can benefit at no cost when
cooperating with us. We are very respectful toward these vendors and if they
ask us not to spread the documentation around, we respect this. But we do not
sign NDAs.

OTOH, Intel has been quite uncooperative by refusing to give us the right to
redistribute the binary firmware images for their PRO/Wireless
2100/2200BG/2915ABG adapters (Centrino). As a consequence, although drivers
for these adapters (ipw and iwi) are included into OpenBSD 3.7, they do not
work out of the box. Users must download the firmware images by hand on the
Intel web site and they are invited to complain to Intel about this before
doing so.

Is there anything that our readers could do to help you
succeed?

Damien Bergamini: Buy hardware made by open-source-friendly
vendors (there is almost always a choice) and continue to contact the closed
vendors. It has proven to be effective in the past.

And to the Linux "vendors" that regardlessly ship non-free firmware images
with their OSes, I'd say that they are playing against their camp. Why would
vendors ever change their policies if such things are accepted by the open
source community?

I read that you have a plan to create a global raidctl
tool to manage all of the different RAID controllers, but you are missing the
necessary documentation from some vendors. Which vendors would you define as
open-source-friendly and which as unsupportive?

Marco Peereboom: Yes, work has started on a tool that will
do universal RAID management; it is actually called bioctl(8)
because it uses the bio(4)ioctl tunnel device. The tool you
mention, raidctl(4), is used for software RAID instead.

The idea behind bioctl(8) is to do as much RAID management as
possible inside of the driver whereas the userland portion remains as simple as
possible.

Unfortunately, there are still vendors out there that believe that there is
IP inside of a hardware API. In my experience this is mostly nonsense, and whenever
there is IP hidden inside an API it only means that the device was architected
poorly. We are talking about filling in some sort of structure, sending it to
the device and awaiting an answer either directly or through a callback. There
is no secret sauce hidden in these numbers that enables competitors to
magically understand what goes on in the firmware.

Reverse-engineering hardware is all about motivation and resources. If a
vendor is motivated enough, it will have to spend considerable resources on
people with specialized knowledge and equipment to X-ray a board in order to
obtain the schematics. It is even harder to reverse engineer programmable chips
like FPGAs and CPLDs. Compared to this, reverse-engineering a software API is
trivial. Hiding an API does not help a vendor in any way, shape, or form, and it
really is silly to keep it hidden as if the farm depends on it.

This release fixes the mirroring mode in ccd. What
types of choices does an OpenBSD user have to set up a RAID array
now?

Michael Shalayeff: As usual, two choices: software or
hardware. All of the drivers we have currently do not support any management, but
we are working on a few that we have enough info to make some management
usable. Software raid(4) however allows full management. For
simple mirroring or striping, ccd(4) provides even better
performance, although it lacks some basic management knobs that I hope to fix
soon.

A lot of companies have been using OpenSSH in their products (Sun
Microsystems, Cisco, Apple, GNU/Linux vendors, etc.). Did they give anything
back, like donations or hardware?

Henning Brauer: Nobody ever gave us anything back. A
plethora of vendors ship OpenSSH--commercial Unix vendors (basically all of
them), all of the Linux distributors, and lots of hardware vendors (like HP in
their switches)--but none of them seem to care; none of them ever gave us
anything back. All of them should very well know that quality software doesn't
"just happen," but needs some funding. Yet, they don't help at all.

This release includes the new OpenSSH 4.1. What's new?

Damien Miller: 4.1 is just a bugfix release; it didn't
include any new features over 4.0. The new features in 4.0 included:

Extending port forwarding to allow it to bind to a user-selected address
rather than just localhost or the wildcard address. This turned out to be a
fair bit of work and discussion to ensure that we didn't break backwards
compatibility.

Added the ability to store hostnames added to
~/.ssh/known_hosts in a hashed format. This is a privacy feature that
prevents a local attacker from learning other hosts that a user has accounts on
from their known_hosts file.

We added at the request of
some MIT researchers who found that a substantial number of user private
keys on shared systems are not encrypted (a really dumb thing to do, BTW). This
lack of user care, coupled with the information in the known_hosts files,
allowed attackers to spread their attacks to multiple systems.

Right now this is disabled by default, but administrators of sites with lazy
users can turn it on with the HashKnownHosts config flag.

If you do this, you should probably also hash your existing
known_hosts file (ssh-keygen -H).

Because the hostname hashing makes it more difficult to manually manage
known_hosts files, we added some tools to ssh-keygen to perform common
operations, like finding listings for hosts and deleting hosts. These work on
hashed as well as plain known_hosts files.

More improvements to the sftp client. In particular, it now
has basic command-line editing and history (no tab-completion yet, though).

As usual, lots of other improvements and bugfixes :)

Does ntpd include any new features?

Henning Brauer:ntpd is not about features.
ntpd is about solving a relatively simple task the right way.
ntpd is about keeping the local machine's clock synchronized with
other ntp servers, no more and no less than that. A plethora of little buttons
and statistics and query tools doesn't gain the majority anything, but imposes
a cost--more complex configuration, and more (potentially buggy) code. Our
ntpd is different. It is supposed to stay small and solve the
task, period.

The only bigger new feature is the -s option, which allows
ntpd to set the machine's clock hard on boot, so it is no longer
required (or even desirable) to run rdate, ntpdate, etc.
beforehand.

I read some complaints about its limited precision. Is this a real
problem for most users?

Henning Brauer: No, not at all. It reaches offsets of way
below 100ms, typically below 50ms. That is about the clock resolution typical
PC hardware reaches. None of the people crying for "better" resolution could
ever give any valid reason why they'd need it--in fact, almost all couldn't
give any at all.

I read that OpenBSD added the support for PIM (Protocol Independent
Multicast). What is it? When is it useful?

Damien Miller: These changes came from FreeBSD and NetBSD
via Pavlin Radoslavov and Ryan McBride. It is the kernel support required to
implement the PIM multicast routing protocols (PIM sparse-mode and PIM
dense-mode). These are the most popular ways to route multicast traffic between
networks.

Note that OpenBSD doesn't have PIM-SM or PIM-DM daemons that can use this
support in the base OS, but you can use Xorp from ports.

Claudio Jeker: PIM replaces the traditional multicast
mechanisms like mrouted or MOSPF to do multicast routing for a
certain area/network. In most cases, group members are sparsely distributed over
this area and protocols like MOSPF are very inefficient in these cases. PIM
introduces two new routing protocols, PIM-SM (Protocol Independent Multicast--Sparse Mode) and PIM-DM (Protocol Independent Multicast--Dense Mode).
Both protocols share the same packet format but the underlying concepts are
different. Currently, xorp (from the ports tree) has support for PIM-SM
on OpenBSD, but I don't know how usable it is.

PIM makes only sense in larger networks that need to do a lot of
multicasting. A possible example are some IP TV solutions that stream every
channel as its own multicast group. This reduces the network load on the
backbone, but the end user is still capable of switching quickly between
channels.

OpenBSD 3.7 includes in-kernel PPPoE support. Previous versions
already have a PPPoE implementation in userland; why is there a kernel-based
one now, too?

Can Erkin Acar: PPP is a protocol for establishing
point-to-point links. It is a quite complicated protocol with many options for
authentication, encryption, and compression. The existing userland
ppp(8) program supports a wide variety of these options and has
been in the tree for a long time. PPPoE (PPP over Ethernet) is a method for
establishing point-to-point links over Ethernet via PPP. Many ISPs provide
broadband services through PPPoE. The userland pppoe(8) program is
used for establishing PPPoE links through ppp(8).

The main problem with userland PPP/PPPoE processing is the overhead. A
single packet has to travel quite a number of times between the kernel and the
userland before finally reaching the TCP/IP stack in the kernel. While not
really noticeable with slow links, high-speed PPPoE links may increase the CPU
utilization and the throughput may be affected.

When the PPPoE processing is moved to the kernel, much of the overhead is
removed. However, the PPP layer inside of the kernel (the sppp layer) supports only a
minimal subset of the PPP protocol. While it is usually enough for connecting
to your ADSL link to your ISP, most of the other bells and whistles are not
available.

OpenBSD's PPPoE (PPP over Ethernet) code is initially ported from NetBSD by
David Berghoff. It was developed and tested outside of the tree until one of the
developers (me) had enough time and motivation (Theo) to put it into the tree.
I modified the initial port to work with our sppp layer, and moved the
functionality of the pppoectl tool into
ifconfig(8).

I continue to work on and improve the sppp layer, which is also shared by the
WAN drivers lmc(4) and san(4).

Claudio Jeker: The userland PPPoE is a bit tricky insofar
as it uses bpf to capture the PPPoE packets from the interface. This was a bit
ugly, as it needs root privileges to use bpf, but since 3.6 PPPoE drops
privileges to user _ppp and chroots after setting the write
filters and locking its bpf descriptor. The in-kernel version of PPPoE accesses
the device in a more natural way and has less overhead--the userland PPPoE
runs two processes and has to pass all data between the two processes and the
kernel. In some cases, it is still better to use the userland PPPoE because
its PPP back end is far more complete than sppp(4) of the
in-kernel PPPoE.

The 3.7 release page shows some new PF features. How does each one
work?

Improved carp(4), new carpdev mode for IP-less
interfaces.

Henning Brauer: Previously, CARP relied on the physical
interface having an IP address in the same subnet as the carp interface. Now
you can leave the physical interface IP-less, by specifying it when configuring
the carp interface, like:

Henning Brauer: This was made to fight (D)DoS attacks.
Basically, IPs with unusual high connection rates are detected, and added to a
table. You can then block them based on that table, or assign them to a very slow
queue or similar. It is also possible to flush all existing states from that IP
when it gets added to the table.

Improved functionality of tags (tag and tagged for translation rules,
tagging of all packets matching state entries).

Henning Brauer: Previously, we only tagged the first packet
of a stateful connection, so that you had to filter statefully. We now tag all
packets.

Henning Brauer: Some error messages have been made more
clear, and some counters were a bit overloaded, so we spread some off. This
allows for a finer view on what pf is doing now.

New keyword set skip on to skip filtering on arbitrary interfaces,
like loopback.

Henning Brauer: It does exactly that--"disable" pf on the
given interface(s).

Filtering on route(8) labels.

Henning Brauer: It is now possible to assign labels to
routes--basically, 32 bytes of arbitrary information that can be used for
almost anything. For example, bgpd could record information about
the source AS number for that route, or about the peer it learned the route
from. pf can then filter based on this information--or apply queuing :)

bgpd cannot set these labels yet, but that's the plan.

What is new in the IPsec/isakmpd arena?

Hans-Joerg Hoexer: For 3.7, we mainly focused on stability
and interoperability: the implementations of the NAT-traversal (NAT-T) and
dead-peer-detection (DPD) features that we shipped with 3.6 were not mature
enough. These issues have been resolved for 3.7. Among many minor bugfixes, we
also made sure that it is possible to run multiple instances of
isakmpd on different ports again.

Ryan McBride added a nice feature for typical roadwarrior setups:
in addition to IP addresses, isakmpd.conf now also understands
interface names and the special keyword default, which selects the address
based on the default route. Thus one does not have to change isakmpd.conf
when the interface address is assigned dynamically.

Did you develop any new feature to fight spam?

Bob Beck: Yes, I've added a "greytrapping" feature to
spamd. This allows a site runner, when greylisting, to make use of
old unused email addresses (or any other ones that spammers like) as spamtraps
for the greylist. This is done by adding the spamtrap address to
spamd's database with the spamdb(8) utility. After
adding:

spamdb -T -a "<bigbutts@obtuse.com>"

if a server is running doing greylisting, any greylisted host who attempts
to mail to the destination address of <bigbutts@obtuse.com>
would be blacklisted for 24 hours. These machines then show up in the
spamd database as TRAPPED entries for the next 24
hours; i.e.:

The spamtrap address has no effect on established WHITE
servers; i.e., mail servers I regularly correspond with could mail to
bigbutts@obtuse.com without being trapped. This only affects hosts
that are a candidate for greylisting; i.e., I haven't exchanged any mail with
them at all (or recently).

Good candidates are any unused address or formerly used address that has
been harvested or appears in a public forum. (in fact, you can pretty much
count on my putting bigbutts@obtuse.com into my spamtrap list
before I even see this article, since spammers like to harvest anything that
looks like an email address to a resolvable domain :)

I have small servers consistently running several hundred
TRAPPED entries, and large ones running TRAPPED lists
fluctuating between 7000 and 10000 entries. These seem to pick up more hosts to
blacklist than the typical spews and spamhaus lists, without any side
effects.

This is the first of several new features to take advantage of the 30-minute
initial delay given by greylisting, as spammers seem to be noticing. Noticing
is good. This means both that it works, and that spammers are easier to identify if they
don't like talking to spamd--have your sendmail
running readers try the following in their sendmailmc
files:

define('confSMTP_LOGIN_MSG', '$j spamd IP-based SPAM blocker; $d')dnl

Reading the
changelog I found a funny point: "The Great Apache Cleanup of 2004 to
remove code we don't use." What is the status of the forked Apache included in
OpenBSD?

Henning Brauer: Well, we're cleaning up the mess, starting
by removing code we don't use. In the end, we hopefully have readable code, and
we're pretty sure we will fix security bugs in the process.

Since the Apache people decided to change their license to an un-free one, we
cannot import newer versions anyway--which is not really a loss, given that they
don't really put any work into the 1.3 tree any more. Our Apache has hundreds of
fixes they didn't take back even before the licensing issue. Now it has even
more, and they still don't have them. We're fixing more stuff on the way, most
often without noticing--we are just fixing bugs.

So, technically, this could be called a fork.

This is the first release that includes X.Org. Why did you choose
to import it instead of XFree86 4.5.0?

Matthieu Herrb: The primary reason is that the new revision
1.1 of the XFree86 license is less free than the old MIT license that had been
used for years by XFree86. OpenBSD already avoided shipping the final XFree86
4.4 release that also uses the new license in 3.6. Then, as many other projects
moved away from XFree86 because of the license, it became obvious that most new
developments in the X window system now take place in X.Org. Having said that,
projects like OpenBSD have to stay vigilant that X.Org doesn't turn into a
Linux-only project (that would slowly slip to a GNU General Public
License).

What new features do package tools support?

Marc Espie: A lot!

The most visible new feature is probably the progress meter. If you
add/remove packages, you will now get instant feedback that something is going
on. A related features is that the message system has been completely
redesigned to be more useful: it's much harder to miss things now.

In general, the system is more robust, handles more fringe cases better,
and is a wee little bit faster. Package tools in 3.7 consume half the memory
they did in 3.6.

Shared library handling has been totally rethought. Packages will now check
that libraries in the base system are present, with the correct version. And
also register and handle inter-package library dependencies fully. From the
ports people point of view, it's now much easier to write correct package
dependencies than it ever was.

The object-oriented packing-list framework has been cleaned up, and is now
used extensively through the whole package system. This is a huge improvement,
because some very nice tricks are now feasible with a few lines of Perl. For
instance:

Packing-lists updates are now 99 percent automatic and correct.

There's a new pkg_mklocatedb tool that you can use to build a
small locate(1) database of files all packages can install. It
took about half an hour to write with the new tools.

Alongside shared libraries, the package system now includes smart ways to
handle:

Fonts

Man pages

Texinfo files

Configuration
files

Shells

And I've probably forgotten a few things along the way. This means that
most special cases (@exec, @unexec, and
INSTALL) are gone. In most cases, you just say "OK, this file is
a man page" and the system will do the right thing. (Heck,
make update-plist will often do the guessing correctly for you.)
For instance, one minor thing you'll notice is the instant update of the
apropos(1) index.

This is way more robust than the old tools. A lots of simple manual
mistakes in making ports with the old tools will just not happen with the new
ones.

OK, I've kept the big one for last.

You can use pkg_add -r foo-1.1 to replace your old
foo-1.0 package with the new foo-1.1 package.

Yes, Virginia, you no longer have to uninstall the old packages before
installing the new ones. pkg_add -r will deal with dependencies
correctly. For instance, assume you want to update xv. You know
it depends on jpeg, png, and tiff.

So you just have to:

pkg_add -r <newjpeg-pkg> <newpng-pkg>
<newtiff-pkg> <newxv-pkg>

and it will just work, by first updating jpeg, then
png, then tiff, and finally xv.

It handles shared libraries correctly, keeping old libraries around until
all packages that need them are updated, and is generally pretty safe.

What is the roadmap for their development?

Marc Espie: Next on my list is handling really complicated
update cases, where you can't update packages individually (for instance, when
files move from package to package, you have to update both packages at
once).

There's also some redesign for dependencies (again) to take updates into
account.

And there's a smarter tool to do updates too. If you read pkg_add
-r's description, you'll notice that you have to specify all of the
packages you want to add. The counterpart would be a pkg_add -u,
where you just say "OK, I want to update those packages, so locate the
replacements, and just do it." We're getting there.

As usual, there's some quality-assurance work to do. Even though
pkg_add -r has seen a lot of testing internally, I'm certain there
will be a minor quirk or two to take care of after the release.

The next very significant change will probably be in the ports tree itself.
A lot of the pkg_tools replacement effort was geared at ensuring
better quality of the ports tree. Well, this is now mostly done. Porting
software has gotten simpler. A lot of mistakes no longer happen. So the
remaining mistakes are, of course, more visible, and need to be taken care
of.

One important policy you'll already see is that we're much more careful in
bumping package names each time we change anything--having update
capabilities mean people will want updates to work. And they will mix and
match packages from various points in time, even though this is not guaranteed
to work. Between very precise package names, and the registration of shared
libraries versions, the package system is doing its best to "get out of the
way" and ensure things will just work, or say in a very obvious way, "Hu, hu,
no, sorry, you really shouldn't do that" if the user does a stupid mistake.

I saw various updates for mac68k. This is not a modern
platform, so what happened?

Martin Reindl: As you noted, pretty much.

OpenBSD on mac68k was rotting away for quite some years. The hardware is
quite slow and there is no fancy stuff like USB or wireless. Nevertheless, the
exotic hardware nature is a valuable proving ground for the kernel APIs and
OpenBSD in general. A nice example how mac68k helped showing bugs was a fix to
gas, so CFLAGS could be set with -pipe
system wide for all architectures.

It all started in fall 2004 when I dusted off a stray NuBus network card. It
was not recognized back then, but the fix was easy. Miod Vallat then contacted
me, gently pushed me in the right directions, and gave me some good information
on where and how to start working if mac68k support should not be dropped. So I
started merging code from NetBSD and after two weeks I had quite a big diff
covering a new interrupt system, much more like the one in the hp300 port, and
a much more flexible serial driver. This in turn allowed Miod to add evcount
support.

Things took off and Claudio Jeker fixed the mc(4) driver as
found on the fastest mac68k, the 840AV. Another long-standing bug was fixed by
Miod, which made it possible switching to bsd.rd as the preferred install
method. (Cutting down the install time from like one day to one hour!) With
this came the ability to finally use more than one disk. Various other
subsystems were also improved, including the driver for the Quadra's onboard
SCSI controller, resulting in much better disk performance (which is mac68k's
weak point). During all of this time Nick Holland, Otto Moerbeek and many other
developers provided rich testing reports and help.

So what we have now is a mac68k port that runs better than ever on Quadra
machines, including new support for the AV machines. Projects for the future
include improved NuBus support, wscons, and pdisk, as well as many small
bugfixes and code merging.

I think people will get excited by the Zaurus port, bringing a
secure SSH-capable machine to their pocket. What is the development
status?

David Gwynne: It is trivial to find an OpenSSH package and
install it on the Zaurus's default Linux distribution. I believe the
availability of these packages is a good demonstration of the effectiveness of
the work that the portable OpenSSH guys are doing.

Personally, I am more interested in having OpenBSD itself and some of its
other features on a wireless device in my pocket. Being able to build a
temporary access point out of a Zaurus with a USB Ethernet device and a
wireless CF card and using four commands to set it up is extremely cool. Apart
from my own needs, I know that people want OpenBSD on the Zaurus for the same
reason they want it on i386 or sparc64 or macppc; they want to use something
they trust and are comfortable with.

The 3.7 release on the Zaurus C3000 is surprisingly usable considering the
short amount of time it has actually been in-tree. It is a functional system
with exactly the same software and ports tree as found on any other
architecture OpenBSD runs on. As for Zaurus hardware, 3.7 ships with support
for its display, keyboard, touchscreen, Compact Flash slot, and the USB
controller. This means that if your USB device works on your desktop or laptop,
you can expect it to work on the Zaurus. The same goes for Compact Flash
devices.

Development is already progressing post-3.7. Power management is constantly
being improved, mostly thanks to Uwe Stuehler. Drivers for the rest of the
onboard Zaurus hardware are being written. For example, Chris Pascoe has
already provided a basic driver for the sound hardware. The Zaurus has become a
popular toy among the developers, so there is a lot of interest in producing
good device support.

Are there any particular limitations?

David Gwynne: In my opinion the biggest limitation is the
need to keep Linux on the device; it is only used as a glorified boot loader
for OpenBSD itself. I would love to see OpenBSD boot up when I press the power
button instead of Linux.

Uwe Stuehler: A minimal fraction of Linux must remain on
internal flash memory in order to run OpenBSD's boot loader. Those who want to
use the whole disk for OpenBSD can do that, assuming they can do well without
the applications that ship with the Zaurus.

The boot loader is mostly the same as on other OpenBSD platforms. It is
conveniently installable via the same package installer that you would use to
install OpenSSH on Linux. Once it is installed, OpenBSD can indeed start
immediately every time you press the power button or reboot the Zaurus.

There are intrinsic limitations of the ARM processor being used in the
Zaurus, such as the lack of a hardware floating-point unit. Our ports tree already
contains alternative software that is better optimized for integer arithmetic
(like mpg321 as an alternative to mpg123). Whatever
gaps currently remain can hopefully be closed as more developers port their
software to various ARM platforms.

Is there any plan to support other devices beyond the Sharp Zaurus
SL-C3000?

David Gwynne: The Zaurus port originally started out on the
SL-C860, but was quickly moved to the C3000 due to the better onboard hardware.
The intention has always been to go back and make OpenBSD work on the C860 once
we're happy with our work on the C3000. In the short term, it might be easy to
support the new C1000, since it is basically a C3000 without a hard disk.
Support for other Zaurus handhelds should be fairly trivial once the C860 and
C3000 are both working, since the same devices and CPUs on these handhelds are
used on other models, too.

Uwe Stuehler: Despite there being certainly at least a little
bit of interest, I think realistically nothing much apart from recent
Zaurus models has a chance to be supported anytime soon.

This release introduce gcc 3.3.5 for common platforms
i386 and macppc. What pros/cons does this version of
gcc bring over the old and patched gcc
2.95?

Pros: a lot of modern C++ code now compiles. There's no way to avoid recent
gcc for some architectures, like AMD64. The various language parsers now give
much better diagnostics. In particular, the new C preprocessor is very
good.

Do you plan to update to gcc 3.4 or 4.0 in the near
future?

Marc Espie: Nope. gcc 3.4 adds a whole set of C++ problems
we don't want to deal with right now (more stringent syntax, catastrophic
memory increases in some cases), and gcc 4.0 is definitely not mature
technology yet, and it's even slower than gcc 3.4.

In a previous interview I did with Richard
Stallman, he stated that gcc will include ProPolice. I hope
this is this good news for you. Is there any other technology that you would
like to see imported into gcc?

Marc Espie: OK, this might be the scoop you're looking
for.

This is not news to me. This is definitely not good news. In this instance,
Richard was all talk, and no action. There is absolutely nothing going on that
indicates that ProPolice will be a part of future GCC releases.

Let me publicize that more. The GCC people are going to say they haven't had
any luck collaborating with Etoh Hiroaki.

I've inquired into the problem, I've offered to help by acting as liaison
between the GCC developers and Etoh Hiroaki. I got a lukewarm response at
best.

Right now, the ProPolice technology is not considered stable enough for
inclusion in GCC. Technically, the stuff Etoh does is a nice hack that plays
interesting games with GCC internals. Those games are actually not really
supported inside of GCC. (ProPolice assumes the frames have a given internal
representation, which is 99 percent the case in practice, but is not part of the GCC
internals' contract.)

And this is it--this is as far as ProPolice integration so far has gone.
Richard asked for ProPolice to be integrated, which does not cost him anything.
It's just a PR move, as far as I'm concerned. No resources have been devoted in
actually pushing for ProPolice to be integrated.

The GCC people are handling other stuff, which is more important for them,
which is something I quite understand.

There is absolutely nothing going on where ProPolice integration is
concerned.

Yes, there's a lot of work. Ask the OpenBSD developers how many issues we
had to solve in gcc in taking ProPolice from the "proof of concept" stage to
"integrated compiler technology in the gcc we ship." Hundreds of hours. Sweat
and blood.

Well, right now, ProPolice stops at GCC 3.4. No one has a working ProPolice
for GCC 4.0. No one is devoting enough resources to ensure this will happen.
And you think we will switch to GCC 4.0? Think again.

Instead, GCC 4.0 will ship with a framework called mudflap, which does about
as much as "flap, flap, flap" flying through code. It catches one valid bound
violation every April the 1st, and complains about valid code every other day
of the year.

No ProPolice in sight.

Federico Biancuzzi
is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.