OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
Kernel relinking status from Theo de Raadt
Contributed by pitrh on Wed Jul 05 05:03:58 2017 (GMT)
from the all tomorrows random gaps dept.

As you may have heard (and as was mentioned in an earlier article), on recent OpenBSD snapshots we have KARL, which means that the kernel is relinked so each boot comes with a new kernel where all .o files are linked in random order and with random offsets. Theo de Raadt summarized the status in a message to the tech@ mailing list, subject kernel relinking as follows:

5 weeks ago at d2k17 I started work on randomized kernels. I've been having conversations with other developers for nearly 5 years on the topic... but never got off to a good start, probably because I was trying to pawn the work off on others.

Having done this, I really had no idea we'd end up where we are today.

Here are the behaviours:

  • The base set has grown, it now includes a link-kit
  • At install time, a unique kernel is built from this link-kit
  • At upgrade time, a unique kernel is built
  • At boot time, a unique kernel is built and installed for the next boot
  • If someone compiles their own kernel and uses 'make install', the link-kit is also updated, so that the next boot can do the work
  • If a developer cp's a kernel to /, the mechanism dis-engages until a 'make install" or upgrade is performed in the future. That may help debugging.

A unique kernel is linked such that the startup assembly code is kept in the same place, followed by randomly-sized gapping, followed by all the other .o files randomly re-organized. As a result the distances between functions and variables are entirely new. An info leak of a pointer will not disclose other pointers or objects. This may also help reduce gadgets on variable-sized architectures, because polymorphism in the instruction stream is damaged by nested offsets changing.

At runtime, the kernel can unmap it's startup code. On architectures where an unmap isn't possible due to large-PTE use, the code can be trashed instead.

I did most of the kernel work on amd64 first, then i386. I explained what needed to be done to visa and patrick, who handled the arm and mips platforms. Then I completed all the rest of the architectures. Some architecture are missing the unmap/trashing of startup code, that's a step we need to get back to.

The next part was tricky and I received assistance from tb and rpe. We had to script the behaviours at build time, snapshot time, relink time, boot time, and later on install/upgrade time also.

While they helped, I also worked to create the "gap.o" file without use of a C compiler so that relinks can occur without the "comp" set installed. This uses the linkscript feature of ld. I don't think anyone has done this before. It is little bit fragile, and the various linkers may need to receive some fixes due to what I've encountered.

To ensure this security feature works great in the 6.2 release, please test snapshots. By working well, I mean it should work invisibly, without any glitch such as a broken kernel or anything. If there are ugly glitches we would like to know before the release.

You heard the man, now is the time to test and get a preview of the new awsomeness that will be in OpenBSD 6.2.


<< On the Insecurity of TIOCSTI | Reply | Flattened | Expanded | Ted Unangst on notable recent changes in OpenBSD >>

Threshold: Help

Related Links
more by pitrh

  Re: Kernel relinking status from Theo de Raadt (mod 0/8)
by Renzo Fabriek ( on Sat Jul 1 20:29:16 2017 (GMT)
  I really like this initiative. Is it unique?

I have only one question. I know if a hacker can adjust the "source" files for rebuilding (relinking) the kernel he is already to far to need it. The same as not installing "comp.tgz" to not provide compiling tools. Does not make a difference if a hacker can modify or add crucial files to gain acces to a system.

Is there any worst case scenario with this which was not present before?
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Kernel relinking status from Theo de Raadt (mod 4/8)
by Anonymous Coward ( on Sun Jul 2 16:25:25 2017 (GMT)
  Does this mean that the kernel binary is keep changing after each boot time, etc? That will make file integrity monitoring difficult because now you can't tell if the checksum change is legitimate or because somebody trojaned my kernel.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Kernel relinking status from Theo de Raadt (mod 3/3)
by Lima ( on Thu Jul 6 12:20:03 2017 (GMT)
  Will this affect boot times/performance in low-end CPU HW (ie Alix)?
how intensive is this relinking thing and at what stage is it done? will be this an optional feature? Thanks.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to April 2nd 2004 as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. Some icons from used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]