Hi,
On 12/6/23 11:26, Vitaly Kuznetsov wrote:
Gerd Hoffmann kraxel@redhat.com writes:
Hi,
Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly?
No. The linux efi stub doesn't need that.
shim.efi does:
(a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs.
(b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi).
Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see
commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi bluca@debian.org Date: Fri May 12 00:55:58 2023 +0100
stub: allow loading and verifying cmdline addons
this AFAIU means that we also need shim in the boot chain if we want to support these addons.
That is true, buts its also false. The LoadImage protocol is more than capable of doing exactly what that patch does (AFAIK), and using strictly the UEFI protocols for validation. Of course if you want to backdoor the process then you need to add shim into it, which is part of what that patch is doing.