AddThis Social Bookmark Button

Print

OpenBSD 3.6 Live

by Federico Biancuzzi
10/28/2004

There is a mounting excitement for the upcoming OpenBSD 3.6 release, as it is the first release that supports multiprocessor systems. To celebrate the event, Federico Biancuzzi interviewed several core developers by email to discuss new features, tools, and future plans.

FB: This is the first OpenBSD release that includes SMP support. Who worked on it?

Niklas Hallqvist: First off, I must tell you that OpenBSD MP support stems from the NetBSD work mainly done by Bill Sommerfeld. Of course, lots of other developers in their camp have added to it; these days I think Frank van der Linden is maintaining the i386 parts. However, stuff like this is impossible to just move over verbatim, and I have spent weeks of work making it fit into our tree. It deserves to be mentioned I got funded by GeNUA for big parts of this work; we thank them for that very kind support.

A handful of other OpenBSD people have done their share as well. Artur Grabowski did the amd64 work; Dale Rahn, Ted Unangst, Hakan Olsson, Andreas Gunnarsson have provided debugging as well as coding help. I am sure a few more, but I don't remember offhand. Lots have helped test, too many to mention. [Dozens] of people donated equipment to make this happen.

FB: What techniques have you chosen?

Niklas Hallqvist: Biglock. That means that while a process is executing inside the kernel, no other process gets access to it; instead they will spin until the first process leaves it. This is a bit crude, since some applications won't benefit at all from this kind of multiprocessing. However, most do, especially if things are set up with multiprocessing in mind.

The reason we have chosen biglock is that it is really simple, and simplicity is a prime objective if security is considered. Fine-grained locking is much harder to do completely right, and things like starvation and deadlocks are much more common. We are just too conservative to risk this.

FB: How does this compare with FreeBSD 4, FreeBSD 5, and DragonFlyBSD?

Niklas Hallqvist: Actually I don't know. I'd expect we'd do worse in anything that is interrupt-intensive. We probably do worse even for the common case where several runnable processes exist simultaneously as well. But ... we do not aim to compete at the edge here. We want to make scalability happen without disrupting our security and robustness track record. We just have other priorities. We will kick SMP out of the tree if it proves to not be trustworthy enough. As it was before we had SMP support, some people had to chose other OSes because we just did not run on big machines enough, so they felt they had to make a compromise on the security to get work done. Hopefully that is not the case anymore.

FB: At the moment the code works on i386 and amd64 platforms. Which platforms do you plan to support in the future?

Niklas Hallqvist: Loose plans, not any guarantees made: alpha, ppc, sparc(64), and maybe mvme88k :-) Maybe the new mips port? Who knows. This is work that probably must be done just because it is fun. There's hardly a large demand with funders around the corner. And today, unfortunately, there's not much time left for fun projects anymore. I was very lucky to get paid to do part of this fun work; otherwise it might not have happened.

FB: The 3.6 kernel includes new timecounter code. Why? Maybe for SMP compatibility?

Artur Grabowski: It's not enabled on any architecture yet, so it's just work in progress. It's definitely not relevant for 3.6. It's relatively important for SMP, since we figured out that it's very hard to access time structures in an MP-safe way. Instead of reinventing the wheel we just took a wheel that someone else has already implemented. It also lets us have precise timekeeping with a central infrastructure, without doing too much hairy work on each architecture. Now, most of the timekeeping code can be shared between architecture.

FB: How does it work? What type of advantages does it bring over the old code?

Artur Grabowski: Check this.

FB: Is there any special hook for OpenNTPD interaction?

Artur Grabowski: Not yet, but we've been talking about it. It won't be a special hook for OpenNTPD, but rather a bunch of hooks for any ntp implementation.

FB: You've introduced a new little tool, OpenNTPD. What is it?

Henning Brauer: Well, as the name says, it's a Network Time Protocol daemon.

FB: Why a new Network Time Protocol daemon?

Henning Brauer: There has been basically only one ntpd around--which has a slight problem with the license--that is huge, runs as root, and doesn't exactly have a promising security record. And it is complex and thus complicated to configure. As a result, the majority of machines out in the wild run without synchronized clocks.

So Theo mentioned that we perhaps should do our own; I liked the idea and sat down and did it. As a result, we have OpenNTPD, which is free, written with security in mind, and easy to use. It of course is privilege separated. (It is a very good example for privilege separation, even: just two message types, one needing privsep because the adjtime syscall requires root privileges, the other--name resolution--requiring access to /etc, thus outside the chroot.) OpenNTPD is really easy to configure, there are just three config file statements. The default config file is perfectly fine for the majority of uses, so for most people, getting synchronized clocks breaks down to enabling ntpd, no configuration needed.

FB: What is the new utility tcpdrop?

Markus Friedl: It allows you to terminate any TCP connection that connects to or originates from the local machine. You specify the connection, and tcpdrop tells the kernel to send out a TCP reset segment and remove the local state associated with this connection.

FB: When would you use it?

Markus Friedl: While working on a fix for a denial of service attack involving out-of-order TCP packets, I've found that it's hard for an administrator to terminate a misbehaving TCP connection. Usually you have to kill the application, unless there is a way to tell it to close a given socket. The attack mentioned before can even lead to situations where closing the socket does not help (e.g., when the connection is in the FIN_WAIT2 state).

Without tcpdrop, you could use a packet-generating tool like libdnet and send out fake TCP resets. However, this is difficult since it requires that the administrator figure out the correct TCP sequence numbers.

FB: Reading some CVS logs, I found the initial tcpdrop commit message saying "drop tcp connections using sysctl(2)." I'm very curious; why sysctl and how does it work?

Markus Friedl: There are two system calls that can be used to add functionality to the kernel (without adding yet another system call): ioctl(2) and sysctl(3). The latter was chosen because it was very simple to implement the new feature. Basically, sysctl allows you to modify a number of kernel variables. These variables are arranged in a tree; the command sysctl net.inet will show the subtree related to the IP protocol. In order to implement the tcpdrop tool, the new sysctl variable net.inet.tcp.drop was added. tcpdrop writes a local address/port and foreign address/port tuple to this variable. This causes the kernel to terminate the matching connection.

FB: OpenSSH 3.9 includes support for session multiplexing. What is it?

Markus Friedl: It allows you to run multiple login shells, scp or sftp sessions over a single SSH connection. For example, you log in to a host and enter your password one time. Then [you] can do multiple scp and sftp sessions to the same host without authenticating again.

FB: Is there anything you can do with it that wasn't possible before?

Markus Friedl: You can use this feature to speed up cvs access over ssh. Usually you have to enter the ssh password for every cvs command. With this feature you start a ssh client, it connects to the cvs server, and you enter the password. Further invocations of ssh will not contact the server directly but pass the connection request to first ssh client process. This client in turn asks the sshd server to start an additional remote process. This way you don't have to reauthenticate. Moreover, it also speeds up the cvs commands because the computationally expensive authentication operations are skipped and the setup requires less round-trip times.

You can use session multiplexing by adding something like this to your .ssh/config:

Host cvs-server
        Hostname cvs-server
        ControlMaster yes
        ControlPath ~/.ssh/cvs-mux
Host cvs-server-fast
        ControlMaster no
        ControlPath ~/.ssh/cvs-mux

Now, open a ssh connection with ssh cvs-server and keep it open. The command

% cvs -d cvs-server-fast:/cvs diff

will use the first connection and will be be faster than

% cvs -d cvs-server:/cvs diff

Damien Miller: Others have been interested in using multiplexing for distributed compilation (distcc and Nikolay Sturm's distributed ports builder). In the distcc case especially, the cost of setting up a new connection would often be greater than the time it takes to compile a single .c file, so the multiplexing support should be a real help.

FB: What is hotplugd?

Alexander Yurchenko: hotplugd(8) is a userland part of the device hot-plugging notification. The main part is in the kernel. It doesn't do anything magic, just hooks into our autoconf(9) framework, which deals with device attachments and detachments. Every time a device attaches or detaches, a corresponding event is queued in the hotplug queue. This queue can be accessed from the userland through the /dev/hotplug device file. This device file supports usual notification mechanisms such as poll(2) and kqueue(2). So the hotplugd(8) daemon waits for events to be read from the /dev/hotplug file. Each event includes the information if it's an attachment or detachment, what's the class and the name of the device that appeared or disappeared. On every event, hotplugd(8) runs shell scripts from the /etc/hotplug directory, where you can describe what you want to do with your devices.

Note that hotplug can only work with [a physical bus] that already has support for hot plugging in its drivers; i.e., pcmcia(4), cardbus(4), and usb(4). SCSI or PCI hot plugging requires some additional work on the drivers.

FB: What type of future uses do you see for it?

Alexander Yurchenko: I use hotplugd(8) to automatically download photos from my camera. You might use it to configure cardbus wifi cards, upload firmware to it, run ppp(3) on ucom(4) when [plugging] your gprs-capable cell phone to usb, and so on. hotplug is for lazy slackers ;-)

Pages: 1, 2, 3

Next Pagearrow