From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Vincent Mailhol" <mailhol@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH v2] efi/libstub: populate LoaderDevicePartUUID
Date: Fri, 04 Sep 2026 18:12:23 +0200 [thread overview]
Message-ID: <b3982808-5ae5-48b8-a677-9f284a764685@app.fastmail.com> (raw)
In-Reply-To: <20260903-efi_stub_bli-v2-1-dbf7ba915117@kernel.org>
Hello Vincent,
On Thu, 3 Sep 2026, at 23:19, Vincent Mailhol wrote:
> The Boot Loader Interface [1] defines LoaderDevicePartUUID. That EFI
> variable records the GPT partition UUID of the partition containing the
> boot loader.
>
> This is used, for example, by systemd-gpt-auto-generator [2] to identify
> the disk the boot loader was launched from and automatically detect and
> mount partitions on it.
>
> GRUB [3] and systemd-boot [4] populate it, but when the kernel is
> started directly by EFI firmware, there is no conventional external boot
> loader to provide the variable. In that case, because the EFI stub
> performs the boot loader role, it should provide the variable itself.
>
Fair enough.
But shouldn't it set LoaderInfo as well then?
> Parse the loaded image device path, extract the GUID signature from its
> GPT HD() node and publish it under the Linux loader entry vendor GUID as
> the volatile LoaderDevicePartUUID EFI variable. Do not overwrite an
> existing variable, so a value supplied by an earlier boot stage keeps
> precedence.
>
> Install the efi_bli_set_variables() hook in both the generic efi-stub.c
> path and the x86-specific x86-stub.c path.
>
> Add CONFIG_EFI_STUB_BLI to make this new feature configurable.
>
I don't think this is needed tbh. Better to enable this unconditionally
so we can rely on this being present in the longer term.
> For an x86_64 build using gcc 15.3.0, bloat-o-meter reports the
> following difference between builds without and with CONFIG_EFI_STUB_BLI:
>
> add/remove: 5/0 grow/shrink: 1/0 up/down: 639/0 (639)
> Function old new delta
> efi_bli_set_variables - 563 +563
> loader_entry_guid - 16 +16
> hex - 16 +16
> guid_index - 16 +16
> device_path_guid - 16 +16
> efi_stub_entry 4180 4192 +12
> Total: Before=29223, After=29862, chg +2.19%
>
> [1] The Boot Loader Interface
> Link: https://systemd.io/BOOT_LOADER_INTERFACE/
>
> [2] systemd-gpt-auto-generator
> Link:
> https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>
> [3] GRUB -- §16.2 bli
> Link:
> https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
>
> [4] systemd -- systemd-boot UEFI Boot Manager
> Link: https://github.com/systemd/systemd/blob/main/docs/BOOT.md?plain=1#L111
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> Changes in v2:
>
> - Add CONFIG_EFI_STUB_BLI to make the BLI feature optional.
>
> - Use static storage for GUID initializers. This reduces the size by
> about 10% compared to v1.
>
> - Remove the redundant NULL check on image.
>
> - Move the nibble-to-ASCII-hex conversion out of efi_bli_guid_to_str()
> into the new efi_bli_nibble_to_hex().
>
> - Rename variables to be closer to the EFI specification.
>
> Link to v1:
> https://lore.kernel.org/r/20260725-efi_stub_bli-v1-1-966e4748077f@kernel.org
> ---
> drivers/firmware/efi/Kconfig | 15 +++++
> drivers/firmware/efi/libstub/Makefile | 2 +
> drivers/firmware/efi/libstub/bli.c | 114
> ++++++++++++++++++++++++++++++++
> drivers/firmware/efi/libstub/efi-stub.c | 1 +
> drivers/firmware/efi/libstub/efistub.h | 6 ++
> drivers/firmware/efi/libstub/x86-stub.c | 1 +
> 6 files changed, 139 insertions(+)
>
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index 29e0729299f5..eff7c6164096 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -100,6 +100,21 @@ config EFI_ARMSTUB_DTB_LOADER
> functionality for bootloaders that do not have such support
> this option is necessary.
>
> +config EFI_STUB_BLI
> + bool "EFI stub Boot Loader Interface support"
> + depends on EFI_STUB
> + default y
> + help
> + The Boot Loader Interface defines EFI variables that expose
> + information about the boot loader to the running OS.
> +
> + Enable this option to let the EFI stub populate the volatile
> + LoaderDevicePartUUID EFI variable when it is missing. This allows
> + user space services such as systemd-gpt-auto-generator to discover
> + partitions on the disk from which the kernel was loaded.
> +
> + If unsure, say Y.
> +
> config EFI_BOOTLOADER_CONTROL
> tristate "EFI Bootloader Control"
> select UCS2_STRING
> diff --git a/drivers/firmware/efi/libstub/Makefile
> b/drivers/firmware/efi/libstub/Makefile
> index 77a2b2d74f3f..000a73a4bc52 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -75,6 +75,8 @@ libfdt-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c \
> lib-$(CONFIG_EFI_PARAMS_FROM_FDT) += fdt.o \
> $(patsubst %.c,lib-%.o,$(libfdt-deps))
>
> +lib-$(CONFIG_EFI_STUB_BLI) += bli.o
> +
> $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
> $(call if_changed_rule,cc_o_c)
>
> diff --git a/drivers/firmware/efi/libstub/bli.c
> b/drivers/firmware/efi/libstub/bli.c
> new file mode 100644
> index 000000000000..d54eb42729a7
> --- /dev/null
> +++ b/drivers/firmware/efi/libstub/bli.c
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/efi.h>
> +#include <linux/errno.h>
> +#include <linux/unaligned.h>
> +
> +#include "efistub.h"
> +
> +struct efi_hd_dev_path {
> + struct efi_generic_dev_path header;
> + u32 partition_number;
> + u64 partition_start;
> + u64 partition_size;
> + efi_guid_t signature;
> + u8 partition_format;
> + u8 signature_type;
> +} __packed;
> +
Please add this to linux/efi.h and add it to the union
in struct efi_dev_path as well.
> +#define EFI_HD_PARTITION_FORMAT_GPT 2
> +#define EFI_HD_SIGNATURE_TYPE_GUID 2
> +
These too
> +static efi_char16_t efi_bli_nibble_to_hex(u8 nibble)
> +{
> + static const char hex[16] __nonstring = "0123456789abcdef";
> +
> + return hex[nibble];
> +}
> +
> +static void efi_bli_guid_to_str(const efi_guid_t *guid, efi_char16_t
> *out)
> +{
> + static const u8 guid_index[UUID_SIZE] = {
> + 3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11, 12, 13, 14, 15,
> + };
> +
> + for (int i = 0; i < ARRAY_SIZE(guid_index); i++) {
> + u8 byte = guid->b[guid_index[i]];
> +
> + *out++ = efi_bli_nibble_to_hex(byte >> 4);
> + *out++ = efi_bli_nibble_to_hex(byte & 0xf);
> +
> + switch (i) {
> + case 3:
> + case 5:
> + case 7:
> + case 9:
> + *out++ = L'-';
> + }
> + }
> +
> + *out = L'\0';
> +}
> +
I'm reluctant to add this kind of code as a special one-off, so I got a
bit carried away and took this code and put it in the stub's printf
layer.
Could you please check whether the first two patches at [0] are
sufficient for efi_bli_guid_to_str() to be replaced by a simple
efi_snprintf("%pUl", ...) call here?
--
Ard.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-libstub-native-utf16
next prev parent reply other threads:[~2026-09-04 16:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 21:19 [PATCH v2] efi/libstub: populate LoaderDevicePartUUID Vincent Mailhol
2026-09-04 16:12 ` Ard Biesheuvel [this message]
2026-09-04 22:06 ` Vincent Mailhol
2026-09-05 12:05 ` Vincent Mailhol
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=b3982808-5ae5-48b8-a677-9f284a764685@app.fastmail.com \
--to=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
/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