From 1228429908db37bef4e4fffe5714a6a0333e08f6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 21 Nov 2025 11:17:49 +0100 Subject: [PATCH 1/5] docs/BOOT_LOADER_INTERFACE: use full variable names once MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We said in the header that "all EFI variables use the vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f", but people not familiar with UEFI might not know that this is concatenated with the variable name. Let's use the full form once — when introducing the variable — to make it easier to grep and search for. While at it, use sembreaks in the document. This makes subsequent changes much easier to review. (It also shows that some sentences are rather long and thus hard to understand.) --- docs/BOOT_LOADER_INTERFACE.md | 232 ++++++++++++++++++---------------- 1 file changed, 125 insertions(+), 107 deletions(-) diff --git a/docs/BOOT_LOADER_INTERFACE.md b/docs/BOOT_LOADER_INTERFACE.md index 981dd1f551..651f41c54f 100644 --- a/docs/BOOT_LOADER_INTERFACE.md +++ b/docs/BOOT_LOADER_INTERFACE.md @@ -7,84 +7,97 @@ SPDX-License-Identifier: LGPL-2.1-or-later # The Boot Loader Interface -systemd can interface with the boot loader to receive performance data and -other information, and pass control information. This is only supported on EFI -systems. Data is transferred between the boot loader and systemd in EFI -variables. All EFI variables use the vendor UUID -`4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`. +systemd can interface with the boot loader +to receive performance data and other information, +and pass control information. +This is only supported on EFI systems. +Data is transferred between the boot loader and systemd in EFI variables. +All EFI variables use the vendor UUID `4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`. +Variables will be listed below using the Linux efivarfs naming, +`-`. -* The EFI Variable `LoaderTimeInitUSec` contains the timestamp in microseconds - when the loader was initialized. This value is the time spent in the firmware - for initialization, it is formatted as numeric, NUL-terminated, decimal - string, in UTF-16. +* The EFI Variable `LoaderTimeInitUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the timestamp in microseconds when the loader was initialized. + This value is the time spent in the firmware for initialization. + It is formatted as numeric, NUL-terminated, decimal string, in UTF-16. -* The EFI Variable `LoaderTimeExecUSec` contains the timestamp in microseconds - when the loader finished its work and is about to execute the kernel. The - time spent in the loader is the difference between `LoaderTimeExecUSec` and - `LoaderTimeInitUSec`. This value is formatted the same way as - `LoaderTimeInitUSec`. +* The EFI Variable `LoaderTimeExecUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the timestamp in microseconds when the loader finished its work and is about to execute the kernel. + The time spent in the loader is the difference between `LoaderTimeExecUSec` and `LoaderTimeInitUSec`. + This value is formatted the same way as `LoaderTimeInitUSec`. -* The EFI variable `LoaderDevicePartUUID` contains the partition GUID of the - ESP the boot loader was run from formatted as NUL-terminated UTF16 string, in - normal GUID syntax. +* The EFI variable `LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the partition GUID of the ESP the boot loader was run from + formatted as NUL-terminated UTF16 string, in normal GUID syntax. -* The EFI variable `LoaderConfigTimeout` contains the boot menu timeout - currently in use. It may be modified both by the boot loader and by the - host. The value should be formatted as numeric, NUL-terminated, decimal - string, in UTF-16. The time is specified in seconds. In addition some - non-numeric string values are also accepted. A value of `menu-force` - will disable the timeout and show the menu indefinitely. If set to `0` or - `menu-hidden` the default entry is booted immediately without showing a menu. - Unless a value of `menu-disabled` is set, the boot loader should provide a - way to interrupt this by for example listening for key presses for a brief - moment before booting. +* The EFI variable `LoaderConfigTimeout-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the boot menu timeout currently in use. + It may be modified both by the boot loader and by the host. + The value should be formatted as numeric, NUL-terminated, decimal string, in UTF-16. + The time is specified in seconds. + In addition some non-numeric string values are also accepted. + A value of `menu-force` will disable the timeout and show the menu indefinitely. + If set to `0` or `menu-hidden` the default entry is booted immediately without showing a menu. + Unless a value of `menu-disabled` is set, + the boot loader should provide a way to interrupt this + by for example listening for key presses for a brief moment before booting. -* Similarly, the EFI variable `LoaderConfigTimeoutOneShot` contains a boot menu - timeout for a single following boot. It is set by the OS in order to request - display of the boot menu on the following boot. When set overrides - `LoaderConfigTimeout`. It is removed automatically after being read by the - boot loader, to ensure it only takes effect a single time. This value is - formatted the same way as `LoaderConfigTimeout`. If set to `0` the boot menu - timeout is turned off, and the menu is shown indefinitely. +* Similarly, the EFI variable `LoaderConfigTimeoutOneShot-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains a boot menu timeout for a single following boot. + It is set by the OS in order to request display of the boot menu on the following boot. + When set overrides `LoaderConfigTimeout`. + It is removed automatically after being read by the boot loader, + to ensure it only takes effect a single time. + This value is formatted the same way as `LoaderConfigTimeout`. + If set to `0` the boot menu timeout is turned off, + and the menu is shown indefinitely. -* The EFI variable `LoaderEntries` may contain a series of boot loader entry - identifiers, one after the other, each individually NUL terminated. This may - be used to let the OS know which boot menu entries were discovered by the - boot loader. A boot loader entry identifier should be a short, non-empty - alphanumeric string (possibly containing `-`, too). The list should be in the - order the entries are shown on screen during boot. See below regarding the - recommended vocabulary for boot loader entry identifiers. +* The EFI variable `LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + may contain a series of boot loader entry identifiers, + one after the other, each individually NUL terminated. + This may be used to let the OS know which boot menu entries were discovered by the boot loader. + A boot loader entry identifier should be a short, non-empty alphanumeric string + (possibly containing `-`, too). + The list should be in the order the entries are shown on screen during boot. + See below regarding the recommended vocabulary for boot loader entry identifiers. -* The EFI variable `LoaderEntryDefault` contains the default boot loader entry - to use. It contains a NUL-terminated boot loader entry identifier. +* The EFI variable `LoaderEntryDefault-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the default boot loader entry to use. + It contains a NUL-terminated boot loader entry identifier. -* The EFI variable `LoaderEntrySysFail` specifies the boot loader entry to be - used in case of a system failure. System failure (SysFail) boot entries can - optionally modify the automatic selection order in the event of a failure, - such as a boot firmware update failure with the failure status recorded in - the EFI system table. If a system failure occurs and `LoaderEntrySysFail` is - set, systemd-boot will use this boot entry, and store the actual SysFail - reason in the `LoaderSysFailReason` EFI variable. +* The EFI variable `LoaderEntrySysFail-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + specifies the boot loader entry to be used in case of a system failure. + System failure (SysFail) boot entries + can optionally modify the automatic selection order in the event of a failure, + such as a boot firmware update failure with the failure status recorded in the EFI system table. + If a system failure occurs and `LoaderEntrySysFail` is set, + systemd-boot will use this boot entry, + and store the actual SysFail reason in the `LoaderSysFailReason` EFI variable. -* The EFI variable `LoaderSysFailReason` contains the system failure reason. +* The EFI variable `LoaderSysFailReason-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the system failure reason. This variable is used in cooperation with `LoaderEntrySysFail` boot entry. If system failure doesn't occur, `LoaderSysFailReason` is not set. -* Similarly, the EFI variable `LoaderEntryOneShot` contains the default boot - loader entry to use for a single following boot. It is set by the OS in order - to request booting into a specific menu entry on the following boot. When set - overrides `LoaderEntryDefault`. It is removed automatically after being read - by the boot loader, to ensure it only takes effect a single time. This value - is formatted the same way as `LoaderEntryDefault`. +* Similarly, the EFI variable `LoaderEntryOneShot-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the default boot loader entry to use for a single following boot. + It is set by the OS + in order to request booting into a specific menu entry on the following boot. + When set overrides `LoaderEntryDefault`. + It is removed automatically after being read by the boot loader, + to ensure it only takes effect a single time. + This value is formatted the same way as `LoaderEntryDefault`. -* The EFI variable `LoaderEntrySelected` contains the boot loader entry - identifier that was booted. It is set by the boot loader and read by - the OS in order to identify which entry has been used for the current boot. +* The EFI variable `LoaderEntrySelected-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the boot loader entry identifier that was booted. + It is set by the boot loader and read by the OS + in order to identify which entry has been used for the current boot. -* The EFI variable `LoaderFeatures` contains a 64-bit unsigned integer with a - number of flags bits that are set by the boot loader and passed to the OS and - indicate the features the boot loader supports. Specifically, the following - bits are defined: +* The EFI variable `LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains a 64-bit unsigned integer with a number of flags bits + that are set by the boot loader and passed to the OS + and indicate the features the boot loader supports. + Specifically, the following bits are defined: * `1 << 0` → The boot loader honours `LoaderConfigTimeout` when set. * `1 << 1` → The boot loader honours `LoaderConfigTimeoutOneShot` when set. @@ -95,27 +108,32 @@ variables. All EFI variables use the vendor UUID * `1 << 6` → The boot loader supports passing a random seed to the OS. * `1 << 13` → The boot loader honours `menu-disabled` option when set. -* The EFI variable `LoaderSystemToken` contains binary random data, - persistently set by the OS installer. Boot loaders that support passing - random seeds to the OS should use this data and combine it with the random - seed file read from the ESP. By combining this random data with the random - seed read off the disk before generating a seed to pass to the OS and a new - seed to store in the ESP the boot loader can protect itself from situations - where "golden" OS images that include a random seed are replicated and used - on multiple systems. Since the EFI variable storage is usually independent - (i.e. in physical NVRAM) of the ESP file system storage, and only the latter - is part of "golden" OS images, this ensures that different systems still come - up with different random seeds. Note that the `LoaderSystemToken` is - generally only written once, by the OS installer, and is usually not touched - after that. +* The EFI variable `LoaderSystemToken-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains binary random data, + persistently set by the OS installer. + Boot loaders that support passing random seeds to the OS + should use this data and combine it with the random seed file read from the ESP. + By combining this random data with the random seed read off the disk + before generating a seed to pass to the OS and a new seed to store in the ESP + the boot loader can protect itself from situations where + "golden" OS images that include a random seed are replicated and used on multiple systems. + Since the EFI variable storage is usually independent + (i.e. in physical NVRAM) of the ESP file system storage, + and only the latter is part of "golden" OS images, + this ensures that different systems still come up with different random seeds. + Note that the `LoaderSystemToken` is generally only written once, + by the OS installer, + and is usually not touched after that. -* The EFI variable `LoaderDeviceURL` contains the URL the boot loader was - downloaded from, in UTF-16 format. Only set in case of network boots. +* The EFI variable `LoaderDeviceURL-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains the URL the boot loader was downloaded from, + in UTF-16 format. + Only set in case of network boots. -* The EFI variable `LoaderTpm2ActivePcrBanks` contains a hexadecimal string - representation of a bitmask with values defined by the TCG EFI Protocol - Specification for TPM 2.0 as EFI_TCG2_BOOT_HASH_ALG_*. If no TPM2 support or - no active banks were detected, will be set to `0`. +* The EFI variable `LoaderTpm2ActivePcrBanks-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` + contains a hexadecimal string representation of a bitmask with values defined by + the TCG EFI ProtocolSpecification for TPM 2.0 as `EFI_TCG2_BOOT_HASH_ALG_*`. + If no TPM2 support or no active banks were detected, will be set to `0`. If `LoaderTimeInitUSec` and `LoaderTimeExecUSec` are set, `systemd-analyze` will include them in its boot-time analysis. If `LoaderDevicePartUUID` is set, @@ -128,12 +146,11 @@ variables. ## Boot Loader Entry Identifiers -While boot loader entries may be named relatively freely, it's highly -recommended to follow the following rules when picking identifiers for the -entries, so that programs (and users) can derive basic context and meaning from -the identifiers as passed in `LoaderEntries`, `LoaderEntryDefault`, -`LoaderEntryOneShot`, `LoaderEntrySelected`, and possibly show nicely localized -names for them in UIs. +While boot loader entries may be named relatively freely, +it's highly recommended to follow the following rules when picking identifiers for the entries, +so that programs (and users) can derive basic context and meaning from the identifiers +as passed in `LoaderEntries`, `LoaderEntryDefault`, `LoaderEntryOneShot`, `LoaderEntrySelected`, +and possibly show nicely localized names for them in UIs. 1. When boot loader entries are defined through the [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/) @@ -141,29 +158,30 @@ names for them in UIs. but with the `.conf` (Type #1 snippets) or `.efi` (Type #2 images) suffix removed. -2. Entries automatically discovered by the boot loader (as opposed to being - configured in configuration files) should generally have an identifier - prefixed with `auto-`. +2. Entries automatically discovered by the boot loader + (as opposed to being configured in configuration files) + should generally have an identifier prefixed with `auto-`. -3. Boot menu entries referring to Microsoft Windows installations should either - use the identifier `windows` or use the `windows-` prefix for the - identifier. If a menu entry is automatically discovered, it should be - prefixed with `auto-`, see above (Example: this means an automatically - discovered Windows installation might have the identifier `auto-windows` or - `auto-windows-10` or so.). +3. Boot menu entries referring to Microsoft Windows installations + should either use the identifier `windows` + or use the `windows-` prefix for the identifier. + If a menu entry is automatically discovered, + it should be prefixed with `auto-`, see above. + (Example: this means an automatically discovered Windows installation + might have the identifier `auto-windows` or `auto-windows-10` or so.). -4. Similarly, boot menu entries referring to Apple macOS installations should - use the identifier `osx` or one that is prefixed with `osx-`. If such an - entry is automatically discovered by the boot loader use `auto-osx` as - identifier, or `auto-osx-` as prefix for the identifier, see above. +4. Similarly, boot menu entries referring to Apple macOS installations + should use the identifier `osx` or one that is prefixed with `osx-`. + If such an entry is automatically discovered by the boot loader use `auto-osx` as identifier, + or `auto-osx-` as prefix for the identifier, see above. -5. If a boot menu entry encapsulates the EFI shell program, it should use the - identifier `efi-shell` (or when automatically discovered: `auto-efi-shell`, - see above). +5. If a boot menu entry encapsulates the EFI shell program, + it should use the identifier `efi-shell` + (or when automatically discovered: `auto-efi-shell`, see above). 6. If a boot menu entry encapsulates a reboot into EFI firmware setup feature, - it should use the identifier `reboot-to-firmware-setup` (or - `auto-reboot-to-firmware-setup` in case it is automatically discovered). + it should use the identifier `reboot-to-firmware-setup` + (or `auto-reboot-to-firmware-setup` in case it is automatically discovered). ## Links From 3e2b026da3ab24366f2693e5b2c6445db07495ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 21 Nov 2025 11:31:12 +0100 Subject: [PATCH 2/5] man/systemd-boot: say that /EFI/systemd/drivers is for hardware In aad0d11e7c6f1f7dcc7b00173140c74b8abf88cc we stopped supporting XBOOTLDR with a different fs driver. This was the primary example that comes to mind when we talk about loading filesystem drivers in the firmware. Since we don't want people to do load such drivers, use a different example. --- man/systemd-boot.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml index c465d4f4f3..8e38503302 100644 --- a/man/systemd-boot.xml +++ b/man/systemd-boot.xml @@ -386,8 +386,8 @@ During initialization, systemd-boot automatically loads all driver files placed in the /EFI/systemd/drivers/ directory of the ESP. The files placed there must have an extension of the EFI architecture ID followed by .efi (e.g. for x86-64 this means - a suffix of x64.efi). This may be used to automatically load file system drivers and - similar, to extend the native firmware support. + a suffix of x64.efi). This may be used e.g. to add support for hardware not + supported natively by the firmware. Enrollment of Secure Boot variables can be performed manually or automatically if files are available under /loader/keys/NAME/{db,dbx,KEK,PK}.auth, NAME From 755637b04ae665012364b3b7c5f816fda6683e48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 21 Nov 2025 11:59:45 +0100 Subject: [PATCH 3/5] docs/BLI: add missing descriptions of feature bits Follow up for 2553a5482c77980429565d14662f309e385bd472, 92bb46c464ffc6f04b633f7d82686a766663ad69, e15d18b4c64e13c37a4c676bf61a5ecf8bba04a3, a67f22c4a73a22312a61dd9352504cd2a960b8a8, e1f1b5fc62f721a3a4c14d97ad01447b2ac07d6d. --- TODO | 4 +++- docs/BOOT_LOADER_INTERFACE.md | 19 +++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/TODO b/TODO index d4dbe7baa7..5bf02b3d5b 100644 --- a/TODO +++ b/TODO @@ -2319,9 +2319,11 @@ Features: ConditionConfigSearchPathNotEmpty= or different syntax? See the discussion starting at https://github.com/systemd/systemd/pull/15109#issuecomment-607740136. -* BootLoaderSpec: Define a way how an installer can figure out whether a BLS +* BootLoaderSpec: define a way how an installer can figure out whether a BLS compliant boot loader is installed. +* BootLoaderSpec: document @saved pseudo-entry, update mention in BLI + * think about requeuing jobs when daemon-reload is issued? use case: the initrd issues a reload after fstab from the host is accessible and we might want to requeue the mounts local-fs acquired through diff --git a/docs/BOOT_LOADER_INTERFACE.md b/docs/BOOT_LOADER_INTERFACE.md index 651f41c54f..659c6ce195 100644 --- a/docs/BOOT_LOADER_INTERFACE.md +++ b/docs/BOOT_LOADER_INTERFACE.md @@ -106,7 +106,26 @@ Variables will be listed below using the Linux efivarfs naming, * `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](/AUTOMATIC_BOOT_ASSESSMENT). * `1 << 5` → The boot loader supports looking for boot menu entries in the Extended Boot Loader Partition. * `1 << 6` → The boot loader supports passing a random seed to the OS. + * `1 << 7` → The boot loader supports loading of drop-in drivers from the `/EFI/systemd/drivers/` directory on the ESP, + see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html). + * `1 << 8` → The boot loader supports the `sort-key` field defined by the + [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification). + * `1 << 9` → The boot loader supports the `@saved` pseudo-entry + * `1 << 10` → The boot loader supports the `devicetree` field defined by the + [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification). + * `1 << 11` → The boot loader support automatic enrollment of SecureBoot keys, + see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html). + * `1 << 12` → The boot loader will set EFI variable `ShimRetainProtocol-605dab50-e046-4300-abb6-3dd810dd8b23` + for `shim` to make its protocol available to the booted binary. * `1 << 13` → The boot loader honours `menu-disabled` option when set. + * `1 << 14` → The boot loader supports multi-profile Unified Kernel Images (UKIs) + * `1 << 15` → The boot loader sets the `LoaderDeviceURL` variable when appropriate. + * `1 << 16` → The boot loader supports the `uki` field defined by the + [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification). + * `1 << 17` → The boot loader supports the `uki-url` field defined by the + [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification). + * `1 << 18` → The boot loader reports active TPM2 PCR banks in the + EFI variable `LoaderTpm2ActivePcrBanks-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`. * The EFI variable `LoaderSystemToken-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f` contains binary random data, From 221a33c412e7146eebda12bdef0270a3af058cc8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 21 Nov 2025 12:06:31 +0100 Subject: [PATCH 4/5] TODO: remove resolved entry Done in https://github.com/uapi-group/specifications/commit/677b722bb8b84625b68162ba201c8461497f9585. --- TODO | 3 --- 1 file changed, 3 deletions(-) diff --git a/TODO b/TODO index 5bf02b3d5b..b1bc038ef5 100644 --- a/TODO +++ b/TODO @@ -1392,9 +1392,6 @@ Features: * chase(): take inspiration from path_extract_filename() and return O_DIRECTORY if input path contains trailing slash. -* document in boot loader spec that symlinks in XBOOTLDR/ESP are not OK even if - non-VFAT fs is used. - * measure credentials picked up from SMBIOS to some suitable PCR * measure GPT and LUKS headers somewhere when we use them (i.e. in From 3cdd80d3e0f4a1a49cc6d3de0e424811fc985a66 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Fri, 21 Nov 2025 12:07:04 +0100 Subject: [PATCH 5/5] sd-boot: correct typos --- man/systemd-boot.xml | 4 ++-- src/bootctl/bootctl-status.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml index 8e38503302..98f0474410 100644 --- a/man/systemd-boot.xml +++ b/man/systemd-boot.xml @@ -57,7 +57,7 @@ A Reboot Into Firmware Interface option, if supported by the UEFI firmware. - Secure Boot variables enrollment if the UEFI firmware is in setup-mode and files are provided + Secure Boot variable enrollment if the UEFI firmware is in setup mode and files are provided on the ESP. @@ -97,7 +97,7 @@ entropy pool initialization, providing a full entropy pool during early boot. The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is - in setup-mode. Additionally, variables can be automatically enrolled if configured. + in setup mode. Additionally, variables can be automatically enrolled if configured. bootctl1 diff --git a/src/bootctl/bootctl-status.c b/src/bootctl/bootctl-status.c index bfd0ced905..4e15576aff 100644 --- a/src/bootctl/bootctl-status.c +++ b/src/bootctl/bootctl-status.c @@ -424,7 +424,7 @@ int verb_status(int argc, char *argv[], void *userdata) { { EFI_LOADER_FEATURE_REPORT_URL, "Loader reports network boot URL" }, { EFI_LOADER_FEATURE_TYPE1_UKI, "Support Type #1 uki field" }, { EFI_LOADER_FEATURE_TYPE1_UKI_URL, "Support Type #1 uki-url field" }, - { EFI_LOADER_FEATURE_TPM2_ACTIVE_PCR_BANKS, "Loader reports TPM2 active PCR banks" }, + { EFI_LOADER_FEATURE_TPM2_ACTIVE_PCR_BANKS, "Loader reports active TPM2 PCR banks" }, }; static const struct { uint64_t flag;