[Ksummit-2012-discuss] [ATTEND] ACPI, UEFI, kernel security
dhowells at redhat.com
Thu Jun 21 21:43:06 UTC 2012
Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> We need to talk about what the kernel needs to provide for UEFI secure
> boot to be possible, since the alternative is miserable failure and
> Linux no longer working on x86 unless people play with the firmware.
> That's going to involve at the very least locking down module loading
> and various kernel interfaces, but figuring out what else needs to be
> covered is fairly important.
Yep. I was about to propose discussing secure boot too.
I've been working on module signing that provides one part of this. We (Red
Hat) have tested the fundamentals in RHEL-4, -5 and -6 and now in Rawhide. I
have a set of patches that seems to work very well, but Rusty has decided to
take a small issue with one bit of. It's a matter of the trade-offs you want
Attached below a quick history/status appraisal of the module signing patches
Module signing patch history and status
I produced some patches a few years ago (2004?) that produce a module signature
on the important bits of the module and metadata that affects them and embeds
this into the module in an ELF note. I believe this was originally based on an
idea or code from Greg - unless it was Rusty.
Private and Public keys are generated during the kernel build. The public key
is compiled into the kernel and the private key is used to sign the modules and
then discarded. With the current gpg, this mandates a source to top up
/dev/random as gpg won't use /dev/urandom. This looks like it will be fixed in
a future version of gpg.
Additional public keys can be added during the kernel build and used to check
Red Hat included these in RHEL-4, RHEL-5 and RHEL-6.
They got posted to LKML a couple of times in the past (Feb 2007 for example)
and each time I got incorrectly personally flamed for being anti-GPL and
I have recently rewritten the crypto patches to do a more generic job of the
crypto side and made them able to use a wider variety of hash algorithms and
crypto algorithms (originally it was just SHA-1 and DSA). The crypto key layer
should be able to handle hardware key stores that can do signature verification
I also optimised the ELF signature checker to be smaller and sleeker after
Rusty complained at how big it was (~4K of code now ~2K).
These patches require minimal changes to userspace stuff. You need to tell the
kernel build to sign the modules and, if you want to, what keys to use/include
- but that's it. Modules are still verifiable after stripping - provided the
strip wouldn't have corrupted the module beyond use anyway (say by removing the
These are currently in Fedora Rawhide and whatever is there will likely turn up
in F-18 when that is forked.
They have been posted to LKML and, fortunately, it seems the original flamers
have lost interest or gone away.
However, to Rusty, embedding in the ELF is a turdlike idea and the signature
should just be cat'd on the end of the file after a magic number, which the
kernel should then search for. We have some differences of opinion on the best
way to handle things, but we're thrashing it out. It's currently looking like
it will involve a new module loader system call, with the signature being
detected and removed from the module in userspace and passed up separately.
One problem with Rusty's idea is that we have to change a bunch of userspace
packages to make it work. The ones I can think of are module-init-tools, kmod,
busybox, dracut, mkinitrd, maybe rpmbuild (and equivalents) and the kernel
specfile (and its equivalents for other distributions).
More information about the Ksummit-2012-discuss