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?

[BarbaraHudson]

Great way to insert a malicious blob for the normal one, and no ability o checksum the entire kernel to detect it.

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:Effects on overall speed?

[Anonymous Coward]

My concern over the technology is that it also can cause a non-deterministic behavior for the platform making it hard to capture elusive bugs. This means that you would need to have a way to be able to load a kernel that's mapped identically to the last time when you perform your test and development.

Bugs that only appears when you have a certain constellation and load order are sometimes wasting weeks of work.

This kind of thing might also expose bugs that were not exposed before, and that, in itself is a good thing. Of course they would likely be very hard to find bugs...

Re:Effects on overall speed?

[Zontar_Thing_From_Ve]

My concern over the technology is that it also can cause a non-deterministic behavior for the platform making it hard to capture elusive bugs. .

Or they could just simply not fix the bugs to take care of that. True story here. I work for a Fortune 500 company in their IT department and I joined them when my previously employer, a startup, was bought out by my current employer. A guy in my management chain was a huge OpenBSD fan, so he made us run some servers using it. Nothing in production used it, but we had some test systems that did. I know I know. Running something in test that isn't like production.... So anyway, he loved OpenBSD with a passion and we couldn't get rid of it while he was there, even though it wasn't used in production at all. We ended up finding a gigantic bug that made OpenBSD's kernel panic and we could make it panic at will. It was caused by a specific piece of hardware in our servers that ran OpenBSD. We and others told Theo and he admitted it was a real problem, but he said he wasn't going to fix it because too few people had this specific hardware. So manager dude finally admitted we couldn't go on like this because not only could we crash the servers at will, they crashed a lot on their own if we did nothing because of the bug. So we replaced all our OpenBSD installations with RedHat and never went back to OpenBSD.

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.