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.