OpenBSD Journal

Kernel relinking status from Theo de Raadt

Contributed by pitrh on 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.

(Comments are closed)


Comments
  1. By Renzo Fabriek (94.210.194.44) on

    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?

  2. By Anonymous Coward (45.76.92.69) on

    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.

    Comments
    1. By Theo (199.185.136.55) deraadt@openbsd.org on de Raadt

      > 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.

      If your kernel is trojaned, how can you run userland code upon it to check if it is trojaned?

      If you are holed, you are holed. Don't get holed.

      Comments
      1. By Anonymous Coward (185.170.42.4) on

        > If your kernel is trojaned, how can you run userland code upon it to check if it is trojaned?
        >
        > If you are holed, you are holed. Don't get holed.

        I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.

        Comments
        1. By Anonymous Coward (199.185.136.55) on

          > > If your kernel is trojaned, how can you run userland code upon it to check if it is trojaned?
          > >
          > > If you are holed, you are holed. Don't get holed.
          >
          > I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.

          And you do that with a CD-ROM every time?


          As to the second point, our bootloader doesn't do that.


          You can disable this security subsystem if you prefer your kernel to have the same address space everytime it runs. Go for it. You can disable this security mechanism, and keep checking with your CD-ROM procedure. Noone is stopping you from using your CD-ROM.

        2. By Anonymous Coward (107.182.226.250) on

          > > If your kernel is trojaned, how can you run userland code upon it to check if it is trojaned?
          > >
          > > If you are holed, you are holed. Don't get holed.
          >
          > I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.

          It would be neat if another stage was added to the boot loader so it could verify signatures of the kernel object files and then does the re-linking before the new kernel boots. Best of both worlds.

          Comments
          1. By Anonymous Coward (81.148.134.38) on

            > > > If your kernel is trojaned, how can you run userland code upon it to check if it is trojaned?
            > > >
            > > > If you are holed, you are holed. Don't get holed.
            > >
            > > I agree, but the checks can be done offline via a trusted OS booted from read-only media (CD-ROM, write-protected USB or floppy), or it can be done by the boot loader if it can be trusted.
            >
            > It would be neat if another stage was added to the boot loader so it could verify signatures of the kernel object files and then does the re-linking before the new kernel boots. Best of both worlds.

            Verify against what? a hacked list of signatures?

            Remember, before booting, there is no OS to help you access remote websites (or even other local storage), so the only source of data is the same place you got the object files.

    2. By Anonymous Coward (88.150.87.179) on

      > 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. chflags schg bsd That does not work on the libraries, but for those it is enough to check the .a files.

  3. By Lima (200.126.211.43) on

    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.

    Comments
    1. By Billy Larlad (69.178.115.138) on

      > 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.

      Don't know how it compares to what's in an Alix, but I've got an Intel Atom D525 (1.8 GHz). The relinking took maybe 45-90 seconds when I updated to the latest snapshot.

Credits

Copyright © - 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 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]