From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>, Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@google.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
"Xu, Min M" <min.m.xu@intel.com>
Subject: [PATCH v2 2/2] efi/libstub: measure EFI LoadOptions
Date: Tue, 20 Sep 2022 14:27:46 +0200 [thread overview]
Message-ID: <20220920122746.3553306-3-ardb@kernel.org> (raw)
In-Reply-To: <20220920122746.3553306-1-ardb@kernel.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 | 10 ++++++++++
drivers/firmware/efi/libstub/efistub.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 8f9a79bc4e8e..c26c59a69c76 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -336,6 +336,7 @@ void efi_apply_loadoptions_quirk(const void **load_options, u32 *load_options_si
enum efistub_event {
EFISTUB_EVT_INITRD,
+ EFISTUB_EVT_LOAD_OPTIONS,
EFISTUB_EVT_COUNT,
};
@@ -352,6 +353,11 @@ static const struct {
INITRD_EVENT_TAG_ID,
STR_WITH_SIZE("Linux initrd")
},
+ [EFISTUB_EVT_LOAD_OPTIONS] = {
+ 9,
+ LOAD_OPTIONS_EVENT_TAG_ID,
+ STR_WITH_SIZE("LOADED_IMAGE::LoadOptions")
+ },
};
static efi_status_t efi_measure_tagged_event(unsigned long load_addr,
@@ -423,6 +429,10 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)
efi_status_t status;
u32 options_chars;
+ if (options_size > 0)
+ efi_measure_tagged_event((unsigned long)options, options_size,
+ EFISTUB_EVT_LOAD_OPTIONS);
+
efi_apply_loadoptions_quirk((const void **)&options, &options_size);
options_chars = options_size / sizeof(efi_char16_t);
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 02fb5f7c8eff..8ad6705b555e 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -762,6 +762,7 @@ union apple_properties_protocol {
typedef u32 efi_tcg2_event_log_format;
#define INITRD_EVENT_TAG_ID 0x8F3B22ECU
+#define LOAD_OPTIONS_EVENT_TAG_ID 0x8F3B22EDU
#define EV_EVENT_TAG 0x00000006U
#define EFI_TCG2_EVENT_HEADER_VERSION 0x1
--
2.35.1
prev parent reply other threads:[~2022-09-20 12:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 12:27 [PATCH v2 0/2] efi: measure kernel command line Ard Biesheuvel
2022-09-20 12:27 ` [PATCH v2 1/2] efi/libstub: refactor the initrd measuring functions Ard Biesheuvel
2022-09-20 12:27 ` Ard Biesheuvel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220920122746.3553306-3-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=daniel.kiper@oracle.com \
--cc=ilias.apalodimas@linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=min.m.xu@intel.com \
--cc=mjg59@google.com \
--cc=pjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox