Bug#906124: Additional debug info

[Somebody else]

On Fri, Aug 17, 2018 at 2:25 PM Ian Campbell <ijc at debian.org> wrote:
>
> On Fri, 2018-08-17 at 10:22 +0200, Somebody else wrote:
> > Any pointers?
>
> Have you seen https://wiki.debian.org/SecureBoot ? I'm not involved in
> that effort but AIUI it describes the plan for what (and why) is going
> through at the moment WRT enabling secure boot out of the box in Debian
> (which, also AIUI, is in line with how other distros are doing things).
>

Yes, I am familiar with this wikipage. And yes, this is in line with
what other Distros are doing. In summary: To enable secureboot out of
the box for systems shipped with Microsoft's keys in the UEFI, Debian
ships a Microsoft-signed "shim bootloader" (contained in the package
'shim-signed') which loads a Debian-signed GRUB2, which loads a
Debian-signed vmlinuz and initrd.

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. This is arguably more secure than the Microsoft-Debian
approach as it prevents evil maid attacks by attackers who have either
gained control of the Debian keys or control of the Microsoft keys.

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. by calling 'grub_efi_locate_protocol'.
This broke my secureboot setup, because I'm not using the shim. My
setup also doesn't require me to recompile any software. Using the
shim however, requires me to compile my own version to embed my own
public key into it. I also fail to see how this aids security.

It's also worth pointing out that the patch in question contains the
following metadata:
>From 90b80a94103bece12cd80e99e71ff7ab75a66e0b Mon Sep 17 00:00:00 2001
From: Colin Watson <cjwatson at ubuntu.com>
Date: Mon, 13 Jan 2014 12:13:19 +0000
Subject: Make linuxefi refuse to boot without shim

This is only intended as a temporary measure.

Forwarded: not-needed
Last-Update: 2013-01-29

Patch-Name: linuxefi_require_shim.patch
---
 grub-core/loader/i386/efi/linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[...]

which is strange, because it's dated to 2014 and it was either just
included in the Debian build, or some other patch had another
side-effect that broke my setup in conjunction with this patch. In any
case, using the log messages that I posted already, I know that this
patch's changes are where the signature validation now fails on my
system. It's also supposedly a "temporary" change that seems to have
been around for a long time, but no context for it is provided.

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 :(. I was
hoping that the maintainer could shed light on what's going on there.