On Tue, 04 Dec 2012 15:41:58 -0800, Christoph Vigano wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 04.12.2012 10:27, Thomas Bächler wrote:

...

If any Arch developer were to magically receive a new, secure-boot secured computer, then we could quickly get shim support.

Well, I'm not an Arch developer, but as it happens I got myself a Thinkpad X230i today, which is capable of secure boot.

If I can be of any help, message me.

Greetings, Christoph

I actually just bought a new laptop with secure boot capable UEFI, and if a generous developer could just release an iso with both the shim and grub-efi installed, then I (and the other Christoph) would gladly try it on our own machines. As far as I know, the only bootloader that the shim currently supports right now is GRUB2, because the shim is actually coded so that grub will call back to the shim to check the MOK list before it boots the kernel. I understand that the developer of rEFInd is fidgeting with his or her bootloader to support the shim.

Am 05.12.2012 10:36, schrieb Thomas Bächler:

We don't understand what to do here at all. That's why we the developer who will be packaging these things needs access to such a machine himself. I'd really have fun figuring this out, but I currently don't want to spend money on a new computer.

I don't plan to buy such a mainboard in the near future either. but in general I would prefer to create our own keys and let the user import those into the firmware. This way we would not depend on prebuild boot loaders signed by Microsoft or anybody else. Security-wise this would also be much saner. But Thomas is right: this has to be implemented and tested by those who own such hardware; which at this time we don't. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

First, I'd like to apologize for sending a very lengthy reply that wasn't attached to this thread. I didn't realize that just because a thread's five days old doesn't mean you can't reply to it. On Mon, 10 Dec 2012 01:28:23 -0800, Thomas Bächler wrote:

Am 10.12.2012 06:54, schrieb kristof:

...

As it stands, Gummiboot doesn't support calling back to Matthew Garrett's shim and until this happens it won't work in secure boot mode.

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):

Date: 2012-12-10 04:20 am The issue is with follow-on boot programs from shim that load EFI executables. Currently, rEFInd and >gummiboot both launch Linux kernels in this way, using the kernel's EFI stub loader to load and launch >the kernel as an EFI application. (So does rEFIt, but it can't pass arguments, so it's very awkward in >this role.) GRUB Legacy, GRUB 2, and ELILO all launch kernels without relying on their EFI stub loaders >or the EFI system calls that are used to launch EFI applications. Therefore, if you sign one of these >boot loaders, it can launch anything. The downside to this is that the commonly-available boot loader >binaries don't verify that a kernel has been signed. The Fedora 18 pre-release archives include a >version of GRUB 2 that performs such checks, but if anybody's done anything with GRUB Legacy or ELILO >that's similar, I don't know about it. The last I checked, Syslinux wasn't an issue because there was >no Syslinux EFI support, although I heard the Syslinux people were working on it.

...

shim signed; shim->GRUB Legacy->kernel and shim->ELILO->kernel both

So in summary, shim->F18 GRUB2->kernel and shim->rEFInd 0.5.0->kernel both now provide authenticated >boot paths; shim->kernel could in principle be authenticated, but this will depend on getting a patched provide an unauthenticated boot >path; and shim->gummiboot->kernel won't work in Secure Boot mode unless/until gummiboot adds shim >support. (Note that I've not tried launching either GRUB Legacy or ELILO directly from shim, so I can't >be sure those paths will actually work.)

From my understanding, an authenticated pathway is not possible because the binaries simply load whatever they want, which effectively disables the web of trust. Calling back to the shim allows the kernel to be inspected for a signature located in the MOK database. I already tried signing gummiboot and vmlinuz with the very same certificate, and while the former was loaded, the latter was denied. On Wed, 05 Dec 2012 07:23:27 -0800, Pierre Schmitz wrote:

I don't plan to buy such a mainboard in the near future either. but in general I would prefer to create our own keys and let the user import those into the firmware. This way we would not depend on prebuild boot loaders signed by Microsoft or anybody else. Security-wise this would also be much saner.

But Thomas is right: this has to be implemented and tested by those who own such hardware; which at this time we don't.

Greetings,

Pierre

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. If bootloader X was recoded to actually check for all further loaded executables to be signed with a key already loaded in the UEFI's database, however, that would work.

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.

If you have a modern system already. You may only actually need a new motherboard or you could try different manufacturer's implementations for the same price as a whole computer, though you would have down time and some (not much) build time. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________

On Mon, 10 Dec 2012 08:26:58 -0800, kristof 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.