No Content, No Fuss: Category openbsd

OpenBSD/Xen boots multi-user

anil@recoil.org (Anil Madhavapeddy) — Mon, 21 Aug 2006 18:08:00 +0100

I've been mentoring a few Xen projects as part of the Google Summer of Code program. One of the most fun is the OpenBSD/Xen porting effort which Christoph Egger has been hacking on. As of a few days ago, if you clone the Mercurial repository for the project, openbsd-xen-sys.hg, and build the kernel with with the i386 bsd.rd, you get the thrill of the following boot log:

[avsm@kremlin ~]$ sudo xm create -c openbsd
Using config file "/etc/xen/openbsd".
Started domain OpenBSD
[ using 187532 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.0-beta (RAMDISK_XENU) #0: Mon Aug 21 14:59:09 BST 2006
    root@mortar.cl.cam.ac.uk:/usr/src/sys/arch/xen/compile/ RAMDISK_XENU
cpu0: Genuine Intel(R) CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0: FPU,V86,DE,TSC,MSR,PAE,MCE,CX8,APIC,MCA,CMOV,
    PAT,PSE36,CFLUSH,ACPI,MMX,SSE,SSE2,SS,HTT,TM,SBF,PNI,
    EST,CNXT-ID
cpu0: EST: unknown system bus clock
real mem  = 62554112 (61088K)
avail mem = 55603200 (54300K)
using 789 buffers containing 3231744 bytes (3156K) of memory
mainbus0 (root)
cpu0 at mainbus0
hypervisor0 at mainbus0
debug virtual interrupt using event channel 3
xenbus0 at hypervisor0: Xen Virtual Bus Interface
xencons0 at hypervisor0: Xen Virtual Console Driver
xencons0: console major 86, unit 0
xencons0: using event channel 2
npx0 at hypervisor0: using exception 16
Xen clock: using event channel 4
rd0: fixed, 3800 blocks
xenbus0: using event channel 1
xennet0 at xenbus0 id 0: Xen Virtual Network Interface
xennet0: MAC address 00:16:3e:05:83:11
xennet0: using event channel 5
root on rd0a
rootdev=0x1100 rrootdev=0x2f00 rawdev=0x2f02
erase ^?, werase ^W, kill ^U, intr ^C, status ^T
(I)nstall, (U)pgrade or (S)hell?

Christoph has done a superb job of porting the NetBSD/Xen code over to OpenBSD. There are still a few bugs to be worked out in the networking driver, the virtual block driver to finish up, and the rather more messy job of getting the user-land tools to run if we want an OpenBSD dom0. But this initial booting is fantastic to see!

A final nice teaser from the console shell:

# ifconfig -a
lo0: flags=8008<LOOPBACK,MULTICAST> mtu 33224
        groups: lo
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 1460
        groups: carp
enc0: flags=0<> mtu 1536
xennet0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:16:3e:05:83:11
        media: Ethernet autoselect (autoselect)

C2K5 thoughts

avsm — Sat, 04 Jun 2005 16:14:18 +0100

Finally had some time to get back from the OpenBSD hackathon and take stock of what I worked on. It was pretty interesting one this year, as I went without having much idea of what to work on (unlike last year, when I had a mad backlog to catch up on). Some stuff I did during the week included:

Clean up the atomicio interface used in OpenSSH and nc(1) to provide simpler semantics. Error checking from read/write functions are a real headache in C, as the functions return -1 on error, which means a signed ssize_t is returned. However, they accept an unsigned value as the size of the buffer to process, which means they could potentially return a value outside the range of the return value. This means you have to check if the return is -1, which indicates an error, and otherwise cast to a size_t to correctly get the buffer size back. With the new atomicio, it always returns a size_t, and returns 0 to signal an error (with errno containing the error, and EPIPE being set for an EOF condition).
Start looking at the Bluetooth stack to get L2CAP and RFCOMM support. We are half-way through un-netgraphing the FreeBSD stack and having a more traditional netbt socket interface (much like netinet or netinet6) to Bluetooth.
Use CIL to implement a few fun kernel source->source transforms. kerneltrace just accepts a regular expression and inserts a printf in the function prologue which outputs the function name and any arguments passed into it. Had this idea when chatting with Marius, and it turned out to be very useful when trying to figure out dataflow in the Bluetooth stack (just compile with make CC="/usr/local/bin/cilly --dokerneltrace --trace-regexp='ubt|ng_blue'"). The second one was even simpler; randomvars assigns a non-zero value to every local variable in a function call to help track down uninitialized-local-variable bugs. Heres one Chad Loder found in mg(1).
Other random signed/unsigned cleanups in OpenSSH. Boring but important I guess...

All in all, the hackathon re-motivated me to continue work on the OCaml-based daemons that Dave and I have been hacking on. I don't want to be fixing random buffer or integer overflows in an OpenBSD hackathon 5 years from now; we need to move on to more high-level issues.

OpenBSD Hackathon in Royal visit shocker!

avsm — Wed, 25 May 2005 23:58:19 +0100

The hackathon is drumming along nicely, with all kinds of crazy diffs being committed. However, all of us have been rather worried about the lack of Royal appreciation for the hard work put in by the OpenBSD development team. Luckily, word of the hackathon has spread far and wide, and the photos below reveal exclusively how the Queen now endorses^* OpenBSD!

^{* "Endorsement" does not imply actual endorsement, but rather "passing within 100 metres of project".}

A Royal Steed

The crowds gather excitedly

Yes!! That pixel is the Queen!!

mmap-based malloc on OpenBSD

avsm — Mon, 09 Aug 2004 00:02:08 +0100

Thierry Deval has recently committed an impressive implementation of malloc that uses mmap instead of the older sbrk to allocate memory in OpenBSD. The advantage of the new approach is that it allows all the neat randomization features that have been added to OpenBSD recently to happen transparently in malloc (so that you don't just get consecutive pages back as in most operating systems). The downside is a slight slowdown, but in this age of insane CPUs, who cares?

It has had the side-effect of exposing a number of latent bugs in programs which silently access memory locations larger than the area they malloced; I fixed one which had remained lurking in my gcc bounds checker (see gcc-local) for over a year, and other bugs have cropped up in programs as important as newfs. Until someone goes through the pain of porting the awesome Valgrind to OpenBSD, being able to expose more bugs this way is pretty useful.

Everybody's kernel hacking

avsm — Fri, 11 Jul 2003 00:17:00 +0100

Had a great time in Las Vegas at SAM 03. The conference wasn't up to much apart from a few interesting papers in our session (one on behaviour-based authentication from some guys at Reading was funny and innovative). We did however hire a car and have a really fun day wandering around the desert checking out the natives.
Back in Princeton, the work's pretty hectic. Been stuck deep in the innards of the FreeBSD kernel for the last few days, ripping out bits of code to test out our cunning new networking idea. We got it to work (late) last night, so now it's the spit and polish phase; the most painful ...
On the OpenBSD front, I finally committed the gcc static bounds checker patch I've been playing with for a few months. It found hundreds of really obviously bad bounds to functions such as strlcpy(3) and sscanf(3) in the source and ports trees. The local compiler gurus (Scotty and Sharpy) have suggested various ways to improve it such as interval analysis, so I might hack on that if a burst of free time holds me to ransom any time soon.
PS: T3 was fun!