[arch-dev-public] [arch-general] Secure Boot Support

[Thomas Bächler]

Am 10.12.2012 17:21, schrieb kristof:
>> 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):

Just as I thought: Calling back into shim is necessary/useful if you
want your second-stage bootloader to verify kernel signatures. If you
don't do that, you can probably use just about any UEFI bootloader.

> 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.

Future bootloaders will probably solve this problem by providing proper
verification of kernel and initramfs. For the moment, all that I would
really _want_ to achieve is to make Arch boot flawlessly on Secure Boot
machines without relying on Secure Boot's "Setup Mode" (meaning disabled
verification, which would in turn make Windows 8 angry). Matthew's shim
seems to make this possible.

The rest is a topic for the future.

As I mentioned numerous times, to make this work, we need to have access
to a modern UEFI machine, which we currently don't.

Some users have suggested we use donation money to get a new computer
for one of the developers - while I would not object to a shiny new
computer, I am unsure if this would justify the use of our donations.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20121211/be18d430/attachment.asc>