[arch-general] Secure Boot Support

[kristof]

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 at 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.
>
> 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  
> >shim signed; shim->GRUB Legacy->kernel and shim->ELILO->kernel both  
> 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 at 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.