First, I'd like to apologize for sending a very lengthy reply that wasn't attached to this thread. I didn't realize that just because a thread's five days old doesn't mean you can't reply to it. On Mon, 10 Dec 2012 01:28:23 -0800, Thomas Bächler <thomas@archlinux.org> wrote:
Am 10.12.2012 06:54, schrieb kristof:
As it stands, Gummiboot doesn't support calling back to Matthew Garrett's shim and until this happens it won't work in secure boot mode.
Could you refer to any documentation about this? Why would the boot loader need to call back into shim?
I'm going off of my correspondence with Matthew Garrett in the comments section of a post he wrote concerning the shim. His reply to me when I asked what distros who don't use rEFInd or GRUB in their installation media (like ours) is as follows(from: http://mjg59.dreamwidth.org/20303.html?view=813903&posted=1#cmt813903):
Date: 2012-12-10 04:20 am The issue is with follow-on boot programs from shim that load EFI executables. Currently, rEFInd and >gummiboot both launch Linux kernels in this way, using the kernel's EFI stub loader to load and launch >the kernel as an EFI application. (So does rEFIt, but it can't pass arguments, so it's very awkward in >this role.) GRUB Legacy, GRUB 2, and ELILO all launch kernels without relying on their EFI stub loaders >or the EFI system calls that are used to launch EFI applications. Therefore, if you sign one of these >boot loaders, it can launch anything. The downside to this is that the commonly-available boot loader >binaries don't verify that a kernel has been signed. The Fedora 18 pre-release archives include a >version of GRUB 2 that performs such checks, but if anybody's done anything with GRUB Legacy or ELILO >that's similar, I don't know about it. The last I checked, Syslinux wasn't an issue because there was >no Syslinux EFI support, although I heard the Syslinux people were working on it.
shim signed; shim->GRUB Legacy->kernel and shim->ELILO->kernel both
So in summary, shim->F18 GRUB2->kernel and shim->rEFInd 0.5.0->kernel both now provide authenticated >boot paths; shim->kernel could in principle be authenticated, but this will depend on getting a patched provide an unauthenticated boot >path; and shim->gummiboot->kernel won't work in Secure Boot mode unless/until gummiboot adds shim >support. (Note that I've not tried launching either GRUB Legacy or ELILO directly from shim, so I can't >be sure those paths will actually work.)
From my understanding, an authenticated pathway is not possible because the binaries simply load whatever they want, which effectively disables the web of trust. Calling back to the shim allows the kernel to be inspected for a signature located in the MOK database. I already tried signing gummiboot and vmlinuz with the very same certificate, and while the former was loaded, the latter was denied. On Wed, 05 Dec 2012 07:23:27 -0800, Pierre Schmitz <pierre@archlinux.de> wrote:
I don't plan to buy such a mainboard in the near future either. but in general I would prefer to create our own keys and let the user import those into the firmware. This way we would not depend on prebuild boot loaders signed by Microsoft or anybody else. Security-wise this would also be much saner.
But Thomas is right: this has to be implemented and tested by those who own such hardware; which at this time we don't.
Greetings,
Pierre
This would be an infinitely nicer solution, if it were not for the fact that there aren't any bootloaders available which can insure a completely trusted chain of execution. I can manually specify in the UEFI to load bootloader X signed with Arch's key but bootloader X, unless hardcoded to do so, can't make sure that kernel X and module X are signed by the very same key. This leads to arbitrary code execution and we all know why this is a bad idea. If bootloader X was recoded to actually check for all further loaded executables to be signed with a key already loaded in the UEFI's database, however, that would work.