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

Bug#922251: live-build: support syslinux-efi as (additional) bootloader



Hi Matthijs,

There's quite a lot of text here - I hope it helps! :-)

On Thu, Feb 14, 2019 at 05:18:42PM +0100, Matthijs Kooijman wrote:
>
>> For feature parity, I'd encourage to look into supporting Secure Boot
>> like the grub-efi implementation does, since we are preparing to ship
>> that in Debian 10. It's not much extra work on top of adding the rest
>> anyway.
>Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I
>can't really find anything about this in the code?
>
>Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I
>see that a new efi firmware binary is built using grub-mkimage, so I
>suppose that that image is not already signed, and there is nothing
>suggesting that image is be signed at that time. Looking at binary_iso
>there is also no reference to signing or secure boot.
>
>AFAIU, to support secure boot, you need to sign the bootloader,
>typically using a key from MS. I've read about the Shim bootloader,
>which is signed and typically used to then load grub or other
>bootloaders (signed by the Debian key or other keys included in Shim).
>However, I can see no reference to shim either.
>
>Looking at the grub package more closely, I *think* that it installs shim
>alongside grub when using grub-install, but that is not used here?

MS won't sign GRUB directly due to the licensing. So that's one of the
reasons why shim was developed. It's a small piece of software which
lives entirely in the UEFI environment and can be readily
verified. The shim binary shipped by each distro includes a public key
*specific to that distro* which is used to verify the rest of the
stack that comes afterwards (GRUB -> Linux, normally). Machine Owner
Keys (MOK) can be added too, under the control of the Machine Owner
(hence the name!) rather than by the distro. GRUB has some knowledge
of how SB works, but AFAIK there's not much needed - it's calling into
APIs provided by the UEFI platform and shim underneath it.

Debian has a shim binary signed by Microsoft, including our own
key. We have implemented a process to create signed versions of a very
small number of our own packages:

 * GRUB
 * Linux
 * fwupd
 * fwupdate

and you can find those signed versions in the archive in Sid and
Buster.

In terms of building a grub binary is well-understood, as you can see
in the build/scripts/efi-image script in live-build. But that will
never give you a signed binary. Instead, if you look in the equivalent
efi-image script in the d-i build system you'll see that it's been
updated. For some arches (amd64 only so far, with others to come), we
still build the grubXXXX.efi binary, but where possible we grab the
binary directly from the -signed package in the archive so we can keep
that signature.

For Debian's official live images built with live-wrapper, we just
pull in the same files that d-i has created so we inherit the same SB
support.

>Regardless, how would you suggest we "support Secure Boot" with
>syslinux-efi exactly? AFAICT there is no syslinux-efi image available
>signed with the MS key, and I suspect it is not signed with the Debian
>key or any other key used by shim (also, since syslinux does not seem to
>support key verification on kernels, I guess there is no secure way to
>get syslinux booting under secure boot without compromising secure boot,
>but I might be missing an important point about SB here...).

No, you're correct. syslinux is not in a state to do SB at all, and I
can't see it happening any time soon.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject


Reply to: