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.
Attachment:
signature.asc
Description: OpenPGP digital signature
