OpenBSD Will Get Unique Kernels On Each Reboot (bleepingcomputer.com)

An anonymous reader quotes a report from Bleeping Computer: A new feature added in test snapshots for the upcoming OpenBSD 6.2 release will create a unique kernel every time an OpenBSD user reboots or upgrades his computer. This feature is named KARL -- Kernel Address Randomized Link -- and works by relinking internal kernel files in a random order so that it generates a unique kernel binary blob every time. Currently, for stable releases, the OpenBSD kernel uses a predefined order to link and load internal files inside the kernel binary, resulting in the same kernel for all users. Developed by Theo de Raadt, KARL will work by generating a new kernel binary at install, upgrade, and boot time. If the user boots up, upgrades, or reboots his machine, the most recently generated kernel will replace the existing kernel binary, and the OS will generate a new kernel binary that will be used on the next boot/upgrade/reboot, constantly rotating kernels on reboots or upgrades. KARL should not be confused with ASLR -- Address Space Layout Randomization -- a technique that randomizes the memory address where application code is executed, so exploits can't target a specific area of memory where an application or the kernel is known to run. A similar technique exists for randomizing the memory location where the kernel loads -- called KASLR. The difference between the two is that KARL loads a different kernel binary in the same place, while KASLR loads the same binary in random locations. Currently Linux and Windows only support KASLR.

Comments

Effects on overall speed?

[randomErr]

The rebuilding process shouldn't be that long. Especially if most of the modules are (mostly) precompiled. But with the random order that things will be re-compiled, will a bad order effect the overall performance of the system?

Re:Effects on overall speed?

[windwalkr]

This is certainly true (and I'd assume that kernel devs might be running with this turned off, or some kind of historical logs kept to track what state their kernel was in during a bug) but it's equally true that exercising things in this way could reveal bugs which were otherwise exceedingly rare, leading to better overall code quality.

In practice, I would think that read-write data structures are more likely to exhibit this kind of problem though, not the read-only code. There are certainly edge cases (timing changes, etc.) but it's not like an off-by-one error is going to affect you, like it might with data.

Re: What are the (dis)advantages?

[zwarte piet]

I wouldn't see how if they only change the order in which object files are linked, the routines themselves should be the same and have the same exploit working for them unless the exploit relies on changing code in a fixed position of ram, but then a simple search function to locate the routine to be exploited can be added.

Doesn't uptime defeat this?

[jfdavis668]

Since a lot of servers are up and running for seriously long times, the kernel won't change often. Also, since there are a finite number of permutations, it wouldn't be that hard to find the memory location you are looking for.