Merge ~juliank/grub/+git/ubuntu:juliank/check-signed-kernels into ~ubuntu-core-dev/grub/+git/ubuntu:ubuntu

should actually check both /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c != 0 && /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 != 1. mokutil unhelpfully gives no information about the latter, so you'll need to directly read the files. See /usr/sbin/update-secureboot-policy for examples.

*Ideally*, we would verify that the kernel is not just signed, but signed with a key that's trusted by the firmware (so: found in db, or in MokListRT). Requires a bit more code, but I believe it's warranted.

It now looks at all kernels in /boot, rather then finding via grub.cfg (so we can run before update-grub), checks the policy in the postinst, and only if we are on secure boot.

I have not found any solution to check if it's signed with the right key, though. What I figured out is that sbverify needs a certificate, and mokutil can give me a list of keys.

Comments inline.

One additional concern: the grub maintainer script is not the only place that grub-install might be called. In particular, shim-signed will also call grub-install --target=x86_64-efi from its postinst - as will grub-efi-amd64-signed, which is from a different source package. And with the most recent adjustment of the dependencies (grub-efi-amd64-signed now depends on grub-efi-amd64 | grub-pc; which means some users in 18.04 and newer will actually have grub-pc installed, whose postinst /should not/ fail to configure due to the kernel secureboot question), grub-efi-amd64-signed may actually have its dependencies satisfied even though there are unsigned kernels.

So I think the right place for the grub-check-signatures code to run is as an inlined wrapper of grub-install. Do you agree?

> Comments inline.
>
> One additional concern: the grub maintainer script is not the only place that
> grub-install might be called. In particular, shim-signed will also call grub-
> install --target=x86_64-efi from its postinst - as will grub-efi-amd64-signed,
> which is from a different source package. And with the most recent adjustment
> of the dependencies (grub-efi-amd64-signed now depends on grub-efi-amd64 |
> grub-pc; which means some users in 18.04 and newer will actually have grub-pc
> installed, whose postinst /should not/ fail to configure due to the kernel
> secureboot question), grub-efi-amd64-signed may actually have its dependencies
> satisfied even though there are unsigned kernels.
>
> So I think the right place for the grub-check-signatures code to run is as an
> inlined wrapper of grub-install. Do you agree?

Your review on the last diff said to only check when we are switching the secure boot policy in grub - the only place we can do this is from the grub maintainer scripts, as we need to have the grub version to check against.

We specifically can't do that in grub-install, since grub-install may be used for a lot of stuff other than installing stuff to the ESP. Hence the previous approach checked it in update-grub.

I don't see why grub-pc should not fail due to secure boot if it's on an EFI system in secure boot mode.

A few final comments inline, nothing that should block landing this. Please resolve these comments as you see fit and land this change.