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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxx>
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.
