For those of you who care (and you may not number very many):
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. I'm not
aware of Pierre Schmitz's reasoning for using Gummiboot as opposed to
rEFInd, but if the official archiso is to boot on secure bootable
machines, it'll have to either use rEFInd or Fedora 18's RC's GRUB2 (the
current install media of Fedora 18 uses the latter). These are essentially
the only two options until syslinux gets a stable EFI release and does the
same sort of hardcoded shim support.
Notice I said Fedora's, and not upstream's. Upstream GRUB2 doesn't support
kernel verification against the MOK database yet so Fedora 18 is shipping
a patched version. Assuming we weren't going to wait for GRUB2 to support
secure boot, we could ship Fedora's bootloader instead or apply similar
patchwork, but this goes against Arch philosophy and it might be easier to
simply wait for upstream support.
Regardless of what Arch does the decision will have to come from someone
with much more authority on Arch's direction; either Pierre because he's
the one rolling out the monthly iso or another developer because using
non-vanilla software, even something as critical as a bootloader, isn't
very Arch-like. Someone correct me if I'm wrong. Not only that, but
setting up a system of signing kernels, modules (out-of-tree modules are a
beast that haven't been worked out yet beyond self-signing), and GRUB2 as
well as rEFInd (for those who choose to use a boot manager beyond their
UEFI's) with openssl generated x509 certificates using either Fedora's
pesign (what MJG recommends) or Ubuntu's sbsign (a similar too that I've
used and can guarantee will work) is a bit of work on its own.
Lastly, the shim itself needs to be pulled into [extra] and it should come
with some script like "shim-install" which would simply rename the
grub-efi binary as grubx64.efi and would place the shim in
/boot/efi/EFI/BOOT/x86_64/, renaming it bootx64.efi. Not so difficult at
all, but it's another thing to do.
That's only the technical implementation, however. Documentation would be
tricky considering every manufacturer designs their UEFI implementation a
little bit differently; on my system, I was stumped until I realized that
regardless of the shim being signed by Microsoft's key I had to actually
specify in the interface that I wanted to trust that particular .efi file.
One point of the shim is so that launching Linux on a new machine isn't
anymore daunting than changing the boot device order (I wouldn't worry so
much about this with Arch users, however) but if the user still has to
muck about in firmware that is different for everybody, one of many
purposes has been swiftly defeated.
Anyway, that's pretty much everything that's keeping secure boot from
coming to Arch Linux for now. Well, that, and the fact that no developer
actually owns a UEFI machine with secure-boot support. We'll see what
happens in the future, I suppose.
Thoughts and comments are requested.
