[Ksummit-2012-discuss] [ATTEND] ACPI, UEFI, kernel security
greg at kroah.com
Thu Jun 21 23:07:51 UTC 2012
On Thu, Jun 21, 2012 at 10:43:06PM +0100, David Howells wrote:
> 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
> to choose.
> Attached below a quick history/status appraisal of the module signing patches
> I'm proposing.
> 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.
I did this back in 2002-2003 and wrote it up here:
that was based on work I had done at WireX / Immunix for a DARPA
contract where we signed all userspace binaries and would only run ones
that had a "correct" signature. There was a USENIX paper written about
the failure of that somewhere, I can't remember when/where that was, but
it was probably a few years before that.
> 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.
I think that's a turd-like idea, and like the elf way so much better for
so many different reasons, not the least being:
> 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).
Thanks for pushing this, and rewriting the code all from scratch and
making it work properly for all of these years. It's valuable stuff,
and I really don't know what is bugging Rusty about it, and honestly
think it should go in as is, especially given what Linus said about us
rejecting code, and given the well-proven track-record of this code
living out of tree for so long, and running everyday in so many machines
So, what can I do to convince Rusty that it's ok as-is? Want me to take
it through staging? :)
More information about the Ksummit-2012-discuss