[arch-general] Secure Boot Support

kristof saposcat at myopera.com
Mon Dec 10 12:50:47 EST 2012

On Mon, 10 Dec 2012 08:26:58 -0800, kristof <saposcat at myopera.com> wrote:

> Oh, and some UEFI implementations don't actually allow users to add keys  
> to the database; only remove them. The workaround to this is to delete  
> all keys in the database, which would cause the computer to boot into  
> "setup-mode", where a user could manually start repopulating the key  
> database. However, this would cause the computer to not be able to boot,  
> er, Windows. Some people would like to boot Windows.

Apologies for triple posting (that might be bad form) but I just checked  
my firmware again and I cannot find an option to add keys; only delete all  
keys in the database or reset to factory settings. I'd rather not try the  
former option because I don't know if I'll be able to get my Windows key  
back, but I do suspect that I would be able to add the 'Arch Linux' key  
once I threw out the entire database that I have. I also tried using an  
unsigned Gummiboot just now on secure boot; my firmware still allows me to  
manually specify a .efi file to trust, and Gummiboot indeed loads, but  
vmlinuz still won't load as it's not trusted by the firmware.

The point of this is that UEFI implementations are all different (I guess  
manufacturers just want to be special snowflakes) and utilizing the shim  
makes documentation and implementation a lot easier and a lot more  
unified. The MOK database is the same for all distributions that choose to  
use the shim. It'll be the same on every computer with Arch installed (if  
Arch uses the shim). Adding a key will be an easy process to document. I  
understand the qualms against using anything Microsoft signed (I don't  
like it either) but the source of the shim is available at  
http://www.codon.org.uk/~mjg59/shim-signed/shim-0.2.tar.bz2, and it's a  
trivial task to verify that Microsoft hasn't tampered with the binary.  
There's no arbitrary trust given to foreign entities. The highest  
authority of trust remains with the distribution packagers, because  
they're the ones who sign everything, and its their key(s) that ends up on  
the installation media.

...if anyone else who has a securely bootable UEFI mainboard would like to  
comment on whether or not they can add keys to the firmware, I'd  
appreciate it if they said so.

More information about the arch-general mailing list