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.

Boot Managers (not bootloaders) like rEFInd and Gummiboot require the kernel to be signed with one of the keys present in the UEFI firmware database, since its finally the firmware that is going to launch the kernel EFISTUB as a normal .efi file, and the firmware won't launch unless the key with which the kernel is signed, is present in the firmware database (not

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.

I have a secure-boot capable system ( https://wiki.archlinux.org/index.php/HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge...), but have secure-boot disabled for now. I am also dual-booting Windows 8 x64 Pro, and the only message the upgrade assistant showed was that secure boot was disabled in the system when installing. Windows 8 boots perfectly fine with secure boot disabled in UEFI mode. I even have CSM (BIOS compatibilty layer) disabled in the firmware setup. So I suggest asking

On Tue, Dec 11, 2012 at 3:15 PM, Thomas Bächler <thomas@archlinux.org>wrote: the shim's MOK database, which is independent of firmware key database). Please correct me if I am wrong, but I am not sure even shim's keys might work for EFISTUB. One can create their own keys and enroll that key into the database. More info at http://rodsbooks.com/efi-bootloaders/secureboot.html and http://rodsbooks.com/refind/secureboot.html . people to disable or change secure-boot mode to setup mode in their system before installing Arch, instead of using Microsoft signed shim binary etc. Adding further to this, I would prefer if the user generates, signs the uefi apps and the kernels he/she wants to use him/herself, and also manage the keys by themself, instead of creating a central Arch specific secure-boot key or any key from a dev. Regards. Keshav