Re: Plan of action for Secure Boot support
On Tue, Aug 13, 2013 at 10:54:21PM +0200, Ben Hutchings wrote:
> Colin Watson and Stefano Rivera talked about how Ubuntu had implemented
> Secure Boot and what they believed were the requirements.
>
> Apparently, the Secure Boot spec requires each stage of the boot code to
> validate signatures only until ExitBootServices() is called. (At this
> point the firmware makes some parts of its non-volatile configuration
> inaccessible.)
>
> While some users would probably like to be able to 'lock down' the
> kernel, requiring signed modules and disabling other kernel features
> that allow code injection, this does not seem to be a requirement for
> booting on systems that implement Windows 8 logo requirements in the
> usual way, i.e. that require a Microsoft-signed first stage boot loader.
[...]
> So the plan seems to be:
>
> 1. Colin Watson will prepare dak changes to support upload and subsequent
> signing of EFI executables. (This is an embedded, not detached, signature.)
>
> 2. Steve Langasek will prepare and upload a package of the 'shim' EFI
> boot loader. This will embed our own set of public keys (corresponding
> to those used by dak) and can load any other EFI executable signed by
> one of them. Later, there will be a shim-signed package containing the
> same executable with a Microsoft signature. (This costs money and takes
> several days, but shim should require only very infrequent changes.)
>
> 3. Colin Watson will update the GRUB package to build a to-be-signed
> monolithic EFI executable separate from the package. Then he will add a
> grub-signed package that includes the Debian-signed executable from the
> archive. This executable would be suitable for use on both removable
> media and the installed system.
>
> 4. The kernel team may also need to upload kernel images for signing and
> add linux-image-signed packages with the Debian-signed kernel images.
> This is because some quirks in the kernel should be run before calling
> ExitBootServices().
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.
In scenario a) we would of course need a signed grub and a signed
kernel, but for scenario b) just having a Microsoft-signed
first-stage-loader that could load an unsigned kernel (after
issuing a warning that is is going to run untrusted code when it
is booted with secure boot enabled) would be enough.
Which of these scenarios should Debian implement?
>From what Ben wrote above, it seems to me that the intention is
to implement scenario a). In this case the question is how to
handle self-built kernels, as these would have to be signed by a
key recognized by grub to be bootable. Is there a mechanism to
generate and add local signing keys to the Debian-signed grub so
that it can boot self-signed kernels? If yes, isn't the whole
point of secure boot moot, as any attacker could just use this
mechanism to use a Microsoft-signed shim and a Debian-signed grub
together with added self-signing-keys to boot malicious code?
@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.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: