[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Signature verification in GRUB

From: Geoffrey Thomas
Subject: Re: Signature verification in GRUB
Date: Tue, 9 Oct 2012 18:14:07 -0700
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Tue, 9 Oct 2012, Chris Murphy wrote:

"secure boot"

Basically Fedora 18 will be the first Fedora to support UEFI Secure Boot. They are moving to a shim bootloader before GRUB2 because GRUB2 is GPLv3 licensed, which requires making signing keys available (Installation Method requirement) so users can still make their own modifications and boot the system with those modifications.

The way I understand it is Fedora will use their own shim signed with the Microsoft key, then have the shim load GRUB2. So everything has to be signed or the adventure is pointless.

Another strategy is what SUSE is doing, which is a bit different, and worth looking into as well. This most recent post may be most applicable but sorta depends on understanding the background:

Thanks, I've read all of those posts, and I'm already using Matthew's shim loader. I'm planning on taking a different approach more along the lines of Chromium OS' verified boot:

The difference between Fedora (and SUSE, Ubuntu, etc.) on one side and Chromium OS and us on the other is that the distros are general purpose and support booting any userspace, so there needs to be some restricting of the kernel's capabilities to prevent writing an initscript that e.g. kexecs a trojanned Windows. Matthew is submitting several patches upstream to the kernel to lock down userspace access to kernelspace memory if the kernel has been secure-booted, and I think Fedora at least is planning on module signing and a push towards KMS everywhere, but backporting those patches and switching to module signing would be a pain that I don't think we need to do.

We (and Chromium OS) have the advantage that we're shipping a complete OS image, so if we validate the image, we know that the initscripts and so forth are clean, and we can allow our signed userspace code to modify kernelspace. So if I can validate the OS image from GRUB, I don't need to make a ton of intrusive changes to our kernel and X stack.

Besides, verified boot is a feature we already have been wanting to implement, possibly with the TPM, but Secure Boot makes this available on commodity hardware (instead of requiring a custom ROM as on Chromebooks). And I think GRUB commands for verifying digitally-signed files and for implementing dm-verity would be of general interest, even independent of Secure Boot. Do you agree?

Geoffrey Thomas

reply via email to

[Prev in Thread] Current Thread [Next in Thread]