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

[Keshav P R]

On Tue, Dec 11, 2012 at 3:15 PM, Thomas Bächler <thomas at archlinux.org>wrote:

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

> 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_E430_3254-DAQ),
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
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

>
>
>