]> git.baikalelectronics.ru Git - kernel.git/commit
efi/libstub: measure EFI LoadOptions
authorIlias Apalodimas <ilias.apalodimas@linaro.org>
Fri, 16 Sep 2022 08:14:35 +0000 (11:14 +0300)
committerArd Biesheuvel <ardb@kernel.org>
Tue, 27 Sep 2022 11:26:16 +0000 (13:26 +0200)
commit2fa478f8e9b8c7ad3b8f337f6b020c0dd49f8b20
treeac1a759061e5b0b0ae90f5ad6dc15a31066b4f4a
parent67e02c23466fe2bb8d42fbc5146f9a3b9b393d39
efi/libstub: measure EFI LoadOptions

The EFI TCG spec, in §10.2.6 "Measuring UEFI Variables and UEFI GPT
Data", only reasons about the load options passed to a loaded image in
the context of boot options booted directly from the BDS, which are
measured into PCR #5 along with the rest of the Boot#### EFI variable.

However, the UEFI spec mentions the following in the documentation of
the LoadImage() boot service and the EFI_LOADED_IMAGE protocol:

  The caller may fill in the image’s "load options" data, or add
  additional protocol support to the handle before passing control to
  the newly loaded image by calling EFI_BOOT_SERVICES.StartImage().

The typical boot sequence for Linux EFI systems is to load GRUB via a
boot option from the BDS, which [hopefully] calls LoadImage to load the
kernel image, passing the kernel command line via the mechanism
described above. This means that we cannot rely on the firmware
implementing TCG measured boot to ensure that the kernel command line
gets measured before the image is started, so the EFI stub will have to
take care of this itself.

Given that PCR #5 has an official use in the TCG measured boot spec,
let's avoid it in this case. Instead, add a measurement in PCR #9 (which
we already use for our initrd) and extend it with the LoadOptions
measurements

Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
drivers/firmware/efi/libstub/efi-stub-helper.c
drivers/firmware/efi/libstub/efistub.h