KARL (Kernel Address Randomized Link)

Announced in 2017 by Theo de Raadt, OpenBSD now relinks kernel objects in a random order after every boot.

While this might help against remote attacks, it’s subject to the same issues than KASLR (although I’ve heard good things about NetBSD’s implementation), and like libc symbols randomization, it’s defeated by an arbitrary read. Speaking of KASLR, it’s interesting to mention that OpenBSD doesn’t do kernel memory randomization.

It’s also incompatible with trusted boot, except if you’re willing to automatically resign your new kernel every single time you boot, which would kinda defeat the point.

Also, it seems that Theo de Raadt sees it as a mitigation against BROP:

There are a few mitigation strategies against BROP attack methodology. One can be summarized as “never reuse an address space”. If a freshly linked kernel of this type was booted each time, we would be well on the way to satisfying that. Then other migitations (sic.) efforts come into play.

But since BROP crashes the target a significant number of time, having your server rebooting for a whole week should be enough to tip you that something wrong is going on…

This mitigation is useful against exploits without large-enough infoleaks and attackers without a working a local arbitrary read (either via leaks, or CPU-side-channel-based). It makes relative overwrites harder to exploit, and renders single-pointers leaks moot. It doesn’t add much complexity code-wise nor impacts performances, but it makes debugging awful.

Amusingly, IDA Pro is using a similar technique to watermark their binaries.

In February 2020, Kristen Carlson Accardi from Intel suggested to implement something similar in the Linux kernel.