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

Re: Plan of action for Secure Boot support

On Wed, 2013-08-14 at 11:10 +0200, Karsten Merker wrote:
> Hello,
> how is booting a self-built kernel handled in this case? I am
> rather new to this topic as I currently do not own any
> secure-boot capable hardware, so maybe I am misunderstanding
> something.
> If I understand things right, there would be two general scenarios:
> a) 
> Having a completely "trusted" boot process from firmware to
> kernel.  This would mean that every component (shim, grub,
> kernel) would have to be signed.
> b)
> Simply enabling a user to run Debian without a fully "trusted"
> boot process on hardware that has secure boot enabled, without
> the user having to change the UEFI-setup settings - i.e.  either
> disabling secure boot or having to install an additional set of
> keys in the firmware.  From what I have read up to now, depending
> on the particular UEFI implementation, the former could be rather
> complicated for the user, as there seems to be no standardized
> way to do it and the latter could even be impossible, if the
> particular UEFI implementation does not offer this feature.

If I understand correctly, you will have options (a) and (c): you will
be able to boot a self-built, unsigned, kernel without manual
intervention at boot time.  The kernel will be launched using the native
Linux boot protocol, not as an EFI executable, but I'm not sure how much
this matters in practice.

> @Ben: could you please explain point 4 of your mail a bit more?
> What is meant with "some quirks in the kernel" that need to be
> run before ExitBootServices() is called?  If I understand that
> correctly, this would mean that for hardware on which this is
> true, only signed kernels could be booted.

I think this is the phrasing Colin used, but I'm not sure what he was
referring to.  You may remember there have been serious bugs in the
implementation of the EFI variable store in some machines, and Linux has
had a series of attempted workarounds for these.  At one stage this
involved running some code in the EFI stub that would be bypassed by
using the native Linux boot protocol, and that may be what he meant.
However, this code has been removed now.

There's no reason in theory why GRUB couldn't implement such
workarounds, though it would be more difficult to make it pass any
necessary information about such workarounds into the kernel.

Note that Debian doesn't enable booting Linux as an EFI executable
today, anyway.


Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: