[arch-general] Secure Boot Support
Now that Matthew Garrett's shim is fully featured and publicly available, will Arch be implementing support for secure boot in the near future? For those who haven't seen the news yet: http://mjg59.dreamwidth.org/17542.html and http://mjg59.dreamwidth.org/20303.html give a pretty in-depth description of how to implement this distro-generic solution to secure boot. More technical details on the shim are available here: http://mjg59.dreamwidth.org/19448.html Finally, I found this OpenSUSE dev post pretty helpful in understanding how the MOKs work but it's not a necessary article to read: https://www.suse.com/blogs/uefi-secure-boot-details/ The only work necessary on the packager's part is using Peter Jones' signing tool to sign GRUB2, kernel modules, and the Arch Linux distributed kernel binaries with an Arch Linux "key" that the users would place into the shim's trusted key database. This isn't any more cumbersome than the current package signing procedures, and I think it would go a long way to be one of the first distributions to support secure-boot without having to fiddle with the UEFI. A final note: the shim currently only supports x86_64 machines and it's unknown if Garrett will ever work on a 32-bit binary. That, on top of the fact that Garrett won't be working on an ARM solution because of licensing issues, means that secure boot would simply be an Arch64 specific feature. I'd really like to hear the community's thoughts on this.
On Mon, Dec 3, 2012 at 10:51 PM, kristof <saposcat@myopera.com> wrote: Thanks for these insightful read, I will look forward those article.
Am 04.12.2012 02:51, schrieb kristof:
Now that Matthew Garrett's shim is fully featured and publicly available, will Arch be implementing support for secure boot in the near future?
There is one showstopper to this: To my knowledge, not a single Arch developer or trusted user has a machine to test this on. That said, Matthew Garrett's solution seems easy enough to adopt for us. I don't know how well it would work with other EFI bootloaders than GRUB2. The fact that only x86_64 is support is not a problem: You should use 64 Bit Arch on such a new machine, period. ARM support will obviously be impossible, as Microsoft will not sign shim's key for ARM devices. If any Arch developer were to magically receive a new, secure-boot secured computer, then we could quickly get shim support.
-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQvopGAAoJEOGIwUZuUxpn67cP/jwD7fgLIvwWNUIJIFsrlGm2 f3iomGH3Be9yB2A0NNvOytKVW5UXorjxzznIaVxYC8Z0TSCJfhUkvPt6uqun9W+J TtrkykV3iN98eTUoHQkMy1yYDtbxxeb9g+6uI7enjwffIga//IHdmJrxFWK2qYPK BPBqgvqGvO92Sc2AESMxMM6FQyyhKrWHJ5X/OkvCJQdkUSqGtpvLVuFWaWpOIljz ngqec/h31xlPFcobW44aaSoqk+OegENjn53mWdaG8up2ysJTQsf/ochEcZbsIUIR XtIroDOmp2xFh+Ui1Y01pUx+ufWQl0SD7THflGSSSmgtRbHK/yuUInGCsmYr7Qd/ /c8vCastLnTwzeOFJ0QywrWpU35+S3nD6N/fsc65KaE9rvRBjiorT3tdFP4xfzuQ bly93D5NElq6h7Tt5j4pURDAd78rDhZCLe4UHGhMHjYBQ4W73McaE4sj65uQX5Oy dmTVVivDhytFA7zZOkq01toYinX7/zr8Cri63iXQC9WmmV6VwcXcgCN0Z1KFMDV8 m2k0tE+RqHM9wdjeLbnYk1kEkNeAtGQnFIopd7YxRXYAu68SgqTR34DsRmqEjLdy CXYDMG/xjbJC/+4X8GbXA4Syq4ixJuSoQWLyNuSgI9faSEnU9ijqFxopAU2mHLaV nca/mdxl0TK/fVcpjQph =4GOH -----END PGP SIGNATURE-----
On Tue, 04 Dec 2012 15:41:58 -0800, Christoph Vigano <mail@cvigano.de> 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 00:57, schrieb kristof:
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.
Use archiso to create the ISO yourself, then submit patches.
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.
As far as I understand, you can just place any signed EFI file as grubx64.efi, not just GRUB. Integration of the bootloader into MOK is optional. 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.
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
On Wed, Dec 05, 2012 at 04:23:27PM +0100, Pierre Schmitz wrote:
But Thomas is right: this has to be implemented and tested by those who own such hardware; which at this time we don't.
Seems like a perfect opportunity to spend some hard-earned donation money on a test rig, no? Greetings, Dennis -- 0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C
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 <thomas@archlinux.org> 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 <pierre@archlinux.de> 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.
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.
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) _______________________________________________________________________
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.
On Mon, 10 Dec 2012 08:26:58 -0800, kristof <saposcat@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.
participants (7)
-
Christoph Vigano
-
Dennis Herbrich
-
Kevin Chadwick
-
kristof
-
Martín Cigorraga
-
Pierre Schmitz
-
Thomas Bächler