Bug#906124: Additional debug info

[Colin Watson]

On Fri, Aug 17, 2018 at 03:26:36PM +0200, Somebody else wrote:
> Now, MY setup, which worked up to grub-efi 2.02+dfsg1-4, was such that
> I removed all Microsoft-owned keys from my system and replaced them
> with my own keys. Then I signed a GRUB2 standalone image (created via
> grub-mkstandalone) and booted that from UEFI. A setup that can be
> found on my GitHub https://github.com/jdelic/secureboot/. By setting
> 'check_signatures=enforce' in grub-initial.cfg and bundling my own GPG
> key, Grub would verify that *I* had signed the kernel image, not
> Debian.

I suspect that we'll need to change linuxefi to explicitly permit
kernels that have been verified using the check_signatures mechanism.
It's not such a common case, so nobody's done the work for it yet.

> As far as I can tell right now, 2.02+dfsg1-5 added a patch
> 'debian/patches/linuxefi_require_shim.patch' that requires the shim to
> be present in the boot order.

No, that change was added a long time ago.  The change that caused the
symptoms you observe was the addition of
debian/patches/linuxefi_disable_sb_fallback.patch.

> Patch-Name: linuxefi_require_shim.patch
[...]
> It's also supposedly a "temporary" change that seems to have
> been around for a long time, but no context for it is provided.

I had a different understanding of the UEFI Secure Boot security model
when I wrote that, and I expect I'll revise the text when I next do a
substantial tidy-up of the Debian grub2 patch stack.  Originally I was
of the opinion that we ought to be able to boot unsigned kernels even in
SB mode, which was why I intended that change to be temporary when I
wrote it; but it's since become clear that that isn't going to fly.

linuxefi is still going to need to verify the kernel somehow, but
there's IMO no intrinsic reason to forbid chains of trust that are
constructed with the aid of mechanisms other than shim, e.g. using GPG
signatures.  Somebody just needs to implement that.  It shouldn't be too
hard, although there are some decisions to make about how the code would
best be laid out across grub-core/i386/efi/linux.c and
grub-core/commands/verify.c.

> So unless I'm totally misinterpreting the information available to me
> (which is possible, since Grub's codebase and Debian's version of it
> are not the best documented codebases ever), I think that this patch
> to the best of my knowledge introduced an unnecessary restriction that
> broke my setup and should probably be considered a bug :(.

The new restriction to boot only signed kernels in SB mode is in general
necessary to fit the generally-understood SB security model;
unfortunately your custom setup sits in a corner case that we hadn't
previously heard much about and so isn't handled right now.

-- 
Colin Watson                                       [cjwatson at debian.org]