OpenBSD kernel address randomized link

Posted Jul 13, 2017 10:32 UTC (Thu) by dskoll (subscriber, #1630)
Parent article: OpenBSD kernel address randomized link

How would this interact with so-called Secure Boot? I guess you'd have to sign each new kernel? That could be slightly annoying because you probably don't want a plaintext signing key lying around.

OpenBSD kernel address randomized link

Posted Jul 13, 2017 12:03 UTC (Thu) by matthias (subscriber, #94967) [Link] (1 responses)

When I read the text I first thought: good idea and I saw no problems with secure boot until the rc script came into play. Then I thought O crap.

For secure boot I would design sth. like a boot loader and linker (opposed to just a boot loader). In this scenario, a kernel is a signed tar.gz (or sth. equivalent) containing a buch of .o files. The boot loader and linker would
- be signed itself (signature verified by secure boot)
- check the signature of the kernel
- untar the kernel
- link the kernel
- execute the kernel

Probably this can be achieved with some initramfs and the kexec mechanism. To avoid some overhead (and problems with kexec not always being available), one could implement a grub module. Actually, this is roughly what I was thinking of when starting to read the article.

There could be one additional problem: Where to get good random data in very early boot? Apart from this problem, my solution should be cleaner. E.g., it would also work for embedded systems, without writeable permanent storage. However, it will be more work to implement.

OpenBSD kernel address randomized link

Posted Jul 13, 2017 17:34 UTC (Thu) by Nahor (subscriber, #51583) [Link]

Or the "kernel image" could be the linker + .o files. The bootloader would remain unchanged and load everything in RAM. Then the linker would move the .o files around and link them then execute the normal kernel code.

I think the kernel already has a linker (for modules).
And this also works for IoT devices, where the filesystem is likely RO.

DAX would be an issue though.

All that said, the solution seems so obvious that I'm sure I'm missing something critical...

OpenBSD kernel address randomized link

Posted Jul 15, 2017 0:08 UTC (Sat) by rahvin (guest, #16953) [Link]

For full chain Secure boot signing I thought you already had to sign every kernel.

The shim loads the microsoft signed key, has the bios validate and loads the bootloader, but to retain a secure boot codepath then the bootloader needs to be signed by a key the shim knows, then the bootloader loads the kernel which is signed by a key the bootloader knows, etc, etc, etc. Secure boot arguably isn't much use if you don't sign all the way down the chain to the boot kernel at least. Then if you want to be really secure you have to sign modules, programs and everything after the kernel with a key the kernel can validate. Fully implemented you shouldn't be able to get anything executed during boot that isn't cryptographicly signed and presumably unmodified.

The problem's always been that everything's got to be signed (and presumably the private key isn't available on the disk for someone to start signing stuff) so you can verify nothing's been tampered with. This signing is a non-trivial task. The cool thing is if you can get something like this working you've got a lot of confidence up to that point that nothing unapproved is loaded (although this doesn't protect you from bugs at all). The hard part is getting this simple enough that it's not a 2 day effort to patch security vulnerabilities. I believe they're working towards this goal with the future of secure boot and TPM.