A less than two-month-old project for OpenBSD, kernel address space randomized link (KARL), has turned the kernel into an object that is randomized on every boot. Instead of the code being stored in the same location for every boot of a given kernel, each boot will be unique. Unlike Linux's kernel address space layout randomization (KASLR), which randomizes the base address for all of the kernel code on each boot, KARL individually randomizes the object files that get linked into the binary. That means that a single information leak of a function address from the kernel does not leak information about the location of all other functions.

Theo de Raadt first posted about the idea on the OpenBSD tech mailing list on May 30. He described the current layout of the OpenBSD kernel code, which is effectively the boot code and assembly runtime (in locore.o), followed by the kernel .o files in a fixed order. His post had some changes that would split out the assembly runtime from locore.o and link it and all of the kernel .o files in a random order. The only piece that would be placed at a known address would be locore.o; it would be followed by a randomly sized gap, then by the kernel text that has its .o files arranged in a random order. There would also be random gaps before other sections (i.e. .rodata, .data, and .bss) that are placed after the kernel text.

Once the kernel was booted, locore.o would still contain a reference to the kernel text in the form of the address of main() (at a known offset in locore.o). So, once the kernel is up, locore.o is either unmapped or destroyed depending on the architecture. The idea is to thwart return-oriented programming (ROP) attacks against the kernel, De Raadt said:

That new layout set the stage for KARL, which De Raadt described in a post on June 12. Reworking the layout still means that the execution of a particular kernel version would always have the same addresses. For users of binary kernels provided by OpenBSD, for example, that would mean an attacker simply needs a copy of the kernel to extract the information they need—no real improvement on the current situation.

What KARL does is to ensure that, every time the kernel is booted, it gets a freshly linked version—new addresses for everything, essentially. De Raadt and Robert Peichaer created a "link kit" that contains all of the kernel .o files needed. After each boot, an rc script links a new kernel in the background and installs it. On the next reboot, a different kernel will be run that, in turn, creates the next kernel. De Raadt said that the link process takes less than a second on a fast machine.

There were still some more pieces of the puzzle to solve: kernel relinks were needed at install time, upgrade time, and when users install their own kernels. De Raadt was back with a post on June 30 that solved all of those problems. In particular, unique kernels are automatically built at install, upgrade, and boot time. In addition, if a new kernel is built and installed with "make install" the link kit will be updated with those objects so that the next boot will result in a new kernel. For debugging purposes, though, if someone copies their own kernel to /bsd, the relinks stop happening until they are re-enabled.

De Raadt asked that users test the feature hard, so that it will be ready for the 6.2 release slated for later this year. Overall, it is an interesting feature that should provide more security at a fairly low cost. It also came about quickly—eye-openingly so—though De Raadt said he has been talking about it with various other OpenBSD developers for five years or so (it "never got off to a good start, probably because I was trying to pawn the work off on others"). It is not inconceivable that Linux could do something similar some day, though one might guess that it would take a fair amount longer than a few months and one release cycle to make that kind of change.