Re: Signature verification in GRUB

[Geoffrey Thomas]

On Tue, 9 Oct 2012, Chris Murphy wrote:

> Google
> "secure boot" site:mjg59.dreamwidth.org
>
> 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: 
> http://mjg59.dreamwidth.org/17542.html

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:

http://www.chromium.org/chromium-os/chromiumos-design-docs/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
address@hidden