[PATCH v3 0/2] Add EFI Boot Guard bootloader package & example recipe

[Christopher Obbard]

This patch series adds support for the EFI Boot Guard bootloader
(https://github.com/siemens/efibootguard) to Buildroot. EFI Boot Guard
can be useful when designing systems using A/B slot-based upgrades.

The first patch introduces the EFI Boot Guard bootloader package which
builds the EFI application as well as userspace and host applications.

The second patch adds an example recipe which demonstrates how to use
EFI Boot Guard in a typical EFI boot scenario. This may serve as a
reference for users looking to integrate EFI Boot Guard into their
system.

A later patch series will add an example recipe with integration
between EFI Boot Guard and RAUC, but that is still pending in RAUC
upstream [0].

While EFI Boot Guard can be built for multiple architectures, for now
this patch series only builds the bootloader for x86_64. Support for
additional architectures (including arm, aarch64 and riscv) will come
in a future follow-up patches.

EFI Boot Guard also provides a tool for generating UKI images, which can
then be signed for Secure Boot. For simplicity, this is not enabled in
the example recipe added in this series, but I expect to add it in a
follow-up patch.

The example recipe has been boot-tested on QEMU with OVMF firmware and
I have confirmed the image boots & runs as expected.

Feedback welcome!

[0] https://github.com/rauc/rauc/pull/1450

Signed-off-by: Christopher Obbard <obb...@gmail.com>
---
Changes in v3:
- Rebase on latest master branch
- Fix shellcheck warnings in board/pc-efibootguard/post-build.sh
- Add note that UKI/Secure Boot is not enabled in the example recipe
- Convert example recipe readme.txt to Markdown
- Bring-up EFI Boot Guard tools in example recipe & document usage
- Add note about RAUC integration patch
- Link to v2: https://lore.kernel.org/r/20260419-wip-obbardc-boot-efibootg...@gmail.com

Changes in v2:
- Rebase on top of buildroot 2026.02
- Update efibootguard to v0.22
- Link to v1: https://lore.kernel.org/r/20251219-wip-obbardc-boot-efibootg...@gmail.com

---
Christopher Obbard (2):
boot/efibootguard: new boot package
board/pc-efibootguard: add example EFI Boot Guard recipe

DEVELOPERS | 5 ++
board/pc-efibootguard/README.md | 89 ++++++++++++++++++++++++++++++++
board/pc-efibootguard/genimage.cfg | 59 +++++++++++++++++++++
board/pc-efibootguard/linux.fragment | 15 ++++++
board/pc-efibootguard/post-build.sh | 33 ++++++++++++
board/pc-efibootguard/post-image.sh | 7 +++
board/pc-efibootguard/run-image-qemu.sh | 9 ++++
boot/Config.in | 2 +
boot/efibootguard/Config.in | 37 +++++++++++++
boot/efibootguard/Config.in.host | 8 +++
boot/efibootguard/efibootguard.hash | 3 ++
boot/efibootguard/efibootguard.mk | 60 +++++++++++++++++++++
configs/pc_x86_64_efibootguard_defconfig | 51 ++++++++++++++++++
13 files changed, 378 insertions(+)
---
base-commit: 7418ff13895be20ccdd6ad6d460e6dbf73727637
change-id: 20250207-wip-obbardc-boot-efibootguard-initial-pkg-9d16e4b283fd

Best regards,
--
Christopher Obbard <obb...@gmail.com>

[Christopher Obbard]

This patch adds a new boot package to Buildroot to build the
EFI Boot Guard bootloader from the https://github.com/siemens/efibootguard
repository.

EFI Boot Guard can be chainloaded as an EFI application or used as a
standalone bootloader and can be useful when booting A/B systems.

Add a recipe to build the EFI bootloader application, user-space
tooling & host tooling (both of which are used to manage EFI Boot Guard
configuration).

EFI Boot Guard can be built for multiple architectures, but this initial
patch only builds the EFI bootloader for x86_64.

Signed-off-by: Christopher Obbard <obb...@gmail.com>
---

DEVELOPERS | 3 ++
boot/Config.in | 2 ++
boot/efibootguard/Config.in | 37 +++++++++++++++++++++++
boot/efibootguard/Config.in.host | 8 +++++
boot/efibootguard/efibootguard.hash | 3 ++
boot/efibootguard/efibootguard.mk | 60 +++++++++++++++++++++++++++++++++++++
6 files changed, 113 insertions(+)

diff --git a/DEVELOPERS b/DEVELOPERS
index 125e7f8248..246b1aa44e 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -703,6 +703,9 @@ F: package/perl-sys-mmap/
F: package/perl-time-parsedate/
F: package/perl-x10/

+N: Christopher Obbard <obb...@gmail.com>
+F: boot/efibootguard/
+
N: Colin Foster <colin....@in-advantage.com>
F: package/python-tftpy/
F: package/rauc-hawkbit-updater/
diff --git a/boot/Config.in b/boot/Config.in
index d73d221431..8e6dc7a5cc 100644
--- a/boot/Config.in
+++ b/boot/Config.in
@@ -15,6 +15,8 @@ source "boot/barebox/Config.in"
source "boot/binaries-marvell/Config.in"
source "boot/boot-wrapper-aarch64/Config.in"
source "boot/edk2/Config.in"
+source "boot/efibootguard/Config.in"
+source "boot/efibootguard/Config.in.host"
source "boot/grub2/Config.in"
source "boot/mv-ddr-marvell/Config.in"
source "boot/mxs-bootlets/Config.in"
diff --git a/boot/efibootguard/Config.in b/boot/efibootguard/Config.in
new file mode 100644
index 0000000000..47fd478e8b
--- /dev/null
+++ b/boot/efibootguard/Config.in
@@ -0,0 +1,37 @@
+config BR2_TARGET_EFIBOOTGUARD_ARCH_SUPPORTS
+ bool
+ default y if BR2_x86_64
+ depends on BR2_USE_MMU
+
+config BR2_TARGET_EFIBOOTGUARD
+ bool "efibootguard"
+ depends on BR2_TARGET_EFIBOOTGUARD_ARCH_SUPPORTS
+ depends on BR2_USE_WCHAR
+ select BR2_PACKAGE_GNU_EFI
+ select BR2_PACKAGE_PCIUTILS if BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS
+ help
+ EFI Boot Guard is a UEFI bootloader intended for robust
+ A/B style updates. It arms a hardware watchdog before
+ handing over control to the OS and supports a fail-safe
+ boot mechanism to roll back if a boot attempt fails.
+
+ https://github.com/siemens/efibootguard
+
+if BR2_TARGET_EFIBOOTGUARD
+
+config BR2_TARGET_EFIBOOTGUARD_X86_64
+ bool "x86-64"
+ depends on BR2_x86_64
+ help
+ Select this option if the platform you're targeting has a
+ 64 bits EFI BIOS.
+
+config BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS
+ bool "install tools"
+ help
+ Install the efibootguard user-space tools (e.g.
+ bg_printenv and bg_setenv) on the target. These tools
+ allow reading and updating efibootguard's configuration
+ in user-space.
+
+endif # BR2_TARGET_EFIBOOTGUARD
diff --git a/boot/efibootguard/Config.in.host b/boot/efibootguard/Config.in.host
new file mode 100644
index 0000000000..845c14c079
--- /dev/null
+++ b/boot/efibootguard/Config.in.host
@@ -0,0 +1,8 @@
+config BR2_TARGET_HOST_EFIBOOTGUARD
+ bool "host efibootguard"
+ help
+ Build efibootguard companion tools for the host. These
+ can be used during image creation to inspect and
+ modify the efibootguard configuration data.
+
+ https://github.com/siemens/efibootguard
diff --git a/boot/efibootguard/efibootguard.hash b/boot/efibootguard/efibootguard.hash
new file mode 100644
index 0000000000..6f5a5cf25c
--- /dev/null
+++ b/boot/efibootguard/efibootguard.hash
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256 6c68c541311dcc8c2be0042f7887acc2a24d2ac68a88d426380fdbda9f476ae8 efibootguard-0.22.tar.gz
+sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 COPYING
diff --git a/boot/efibootguard/efibootguard.mk b/boot/efibootguard/efibootguard.mk
new file mode 100644
index 0000000000..c40cef13ac
--- /dev/null
+++ b/boot/efibootguard/efibootguard.mk
@@ -0,0 +1,60 @@
+################################################################################
+#
+# efibootguard
+#
+################################################################################
+
+EFIBOOTGUARD_VERSION = 0.22
+EFIBOOTGUARD_SITE = $(call github,siemens,efibootguard,refs/tags/v$(EFIBOOTGUARD_VERSION))
+EFIBOOTGUARD_LICENSE = GPL-2.0-only
+EFIBOOTGUARD_LICENSE_FILES = COPYING
+
+EFIBOOTGUARD_DEPENDENCIES = \
+ gnu-efi \
+ host-autoconf-archive
+
+ifeq ($(BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS),y)
+EFIBOOTGUARD_DEPENDENCIES += pciutils
+EFIBOOTGUARD_INSTALL_TARGET = YES
+else
+EFIBOOTGUARD_INSTALL_TARGET = NO
+endif
+
+EFIBOOTGUARD_INSTALL_IMAGES = YES
+
+EFIBOOTGUARD_AUTORECONF = YES
+
+EFIBOOTGUARD_AUTORECONF_OPTS = \
+ -I $(HOST_DIR)/share/autoconf-archive
+
+EFIBOOTGUARD_CONF_OPTS = \
+ --with-gnuefi-sys-dir=$(STAGING_DIR) \
+ --with-gnuefi-include-dir=$(STAGING_DIR)/usr/include/efi \
+ --with-gnuefi-lib-dir=$(STAGING_DIR)/usr/lib \
+ --disable-completion \
+ --disable-tests
+
+# TODO: Perhaps take inspiration from Debian patch https://salsa.debian.org/debian/efibootguard/-/blob/master/debian/patches/always-override-stack-protector-variables-in-EFI-bui.patch?ref_type=heads
+EFIBOOTGUARD_CONF_ENV = \
+ LDFLAGS="$(LDFLAGS) -no-pie"
+
+define EFIBOOTGUARD_INSTALL_IMAGES_CMDS
+ $(INSTALL) -d $(BINARIES_DIR)/efibootguard
+ $(INSTALL) -m 0644 $(@D)/efibootguardx64.efi $(BINARIES_DIR)/efibootguard/
+endef
+
+HOST_EFIBOOTGUARD_DEPENDENCIES = \
+ host-autoconf-archive
+
+HOST_EFIBOOTGUARD_AUTORECONF = YES
+
+HOST_EFIBOOTGUARD_AUTORECONF_OPTS = \
+ -I $(HOST_DIR)/share/autoconf-archive
+
+HOST_EFIBOOTGUARD_CONF_OPTS = \
+ --disable-bootloader \
+ --disable-completion \
+ --disable-tests
+
+$(eval $(autotools-package))
+$(eval $(host-autotools-package))

--
2.53.0

[Christopher Obbard]

Add an example recipe (based on configs/pc_x86_64_efi_defconfig) to
generate an x86-64 image which boots the system using the EFI Boot Guard
bootloader. The recipe is an example of how to create an image using
EFI Boot Guard, including how to create the disk image & how to configure
the bootloader.

The created example image contains two boot slots; one of which contains
the environment built by Buildroot and the other is an empty, dummy slot
(e.g. cannot be booted from).

EFI Boot Guard provides a tool for generating UKI images, which can then

be signed for Secure Boot. For simplicity, this is not enabled in the

example recipe.

Also add instructions (and a script) to boot the example image in QEMU.

Signed-off-by: Christopher Obbard <obb...@gmail.com>
---

DEVELOPERS | 2 +

board/pc-efibootguard/README.md | 89 ++++++++++++++++++++++++++++++++
board/pc-efibootguard/genimage.cfg | 59 +++++++++++++++++++++
board/pc-efibootguard/linux.fragment | 15 ++++++
board/pc-efibootguard/post-build.sh | 33 ++++++++++++
board/pc-efibootguard/post-image.sh | 7 +++
board/pc-efibootguard/run-image-qemu.sh | 9 ++++

configs/pc_x86_64_efibootguard_defconfig | 51 ++++++++++++++++++
8 files changed, 265 insertions(+)

diff --git a/DEVELOPERS b/DEVELOPERS
index 246b1aa44e..ddc71d9639 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -704,7 +704,9 @@ F: package/perl-time-parsedate/
F: package/perl-x10/

N: Christopher Obbard <obb...@gmail.com>
+F: board/pc-efibootguard/
F: boot/efibootguard/
+F: configs/pc_x86_64_efibootguard_defconfig

N: Colin Foster <colin....@in-advantage.com>
F: package/python-tftpy/

diff --git a/board/pc-efibootguard/README.md b/board/pc-efibootguard/README.md
new file mode 100644
index 0000000000..1bbeff4c48
--- /dev/null
+++ b/board/pc-efibootguard/README.md
@@ -0,0 +1,89 @@
+# EFI Boot Guard Example Recipe
+
+This recipe creates a basic x86 disk image using [EFI Boot Guard](https://github.com/siemens/efibootguard/tree/master)
+as the bootloader with two root filesystem slots.
+
+The image is intended to demonstrate a typical A/B boot layout. The first slot is
+populated with the root filesystem generated as part of the Buildroot build,
+while the second slot is left empty so that it can be used later by an update
+tool, which is out-of-scope for this example recipe.
+
+The recipe also creates the EFI system partition and installs the EFI Boot Guard
+bootloader components needed to select and boot one of the available slots. Each
+slot has its own EFI Boot Guard environment, containing the kernel image and
+configuration.
+
+This example is deliberately minimal. It is intended as a reference for users who
+want to integrate EFI Boot Guard into their own platform-specific images, rather
+than as a complete production-ready update setup.
+
+This recipe was designed to be ran in QEMU and may need additional changes to run
+on real hardware.
+
+
+## Build the image
+
+Configure Buildroot with:
+
+```
+$ make pc_x86_64_efibootguard_defconfig
+```
+
+
+Build the image with:
+
+```
+$ make
+```
+
+The raw disk image is available under `output/images/disk.img`.
+
+
+## Emulation in QEMU
+
+Emulate the system in QEMU with:
+
+```
+$ qemu-system-x86_64 \
+ -M pc \
+ -drive if=pflash,format=raw,readonly=on,file=</path/to/OVMF_CODE.fd> \
+ -drive file=output/images/disk.img,if=virtio,format=raw \
+ -boot menu=on \
+ -net nic,model=virtio \
+ -net user
+```
+
+Note that `</path/to/OVMF.fd>` needs to point to a valid x86_64 UEFI
+firmware image for qemu. It may be provided by your distribution as a
+edk2 or OVMF package, in a path such as `/usr/share/OVMF/OVMF_CODE_4M.fd` in
+Debian.
+
+
+## EFI Boot Guard userspace tools
+
+The example image includes the EFI Boot Guard userspace tools. These can be used
+to inspect and update the boot metadata stored in each slot environment.
+
+`bg_printenv` prints the current EFI Boot Guard boot configuration:
+
+```
+# bg_printenv
+```
+
+`bg_setenv` updates the state and revision of a slot. For example, the following
+commands initialise both slots and prefers booting from slot `0`:
+
+```
+# bg_setenv --part 0 --ustate OK --revision 1
+# bg_setenv --part 1 --ustate OK --revision 0
+```
+
+In this example, both slots are marked as usable, but slot `0` has the higher
+revision. EFI Boot Guard will therefore select it before slot `1`.
+
+For more information on configuring EFI Boot Guard, see the
+[upstream documentation](https://github.com/siemens/efibootguard/blob/master/README.md).
+
+An update framework (such as RAUC) can use these tools to switch the preferred
+boot slot after installing an update and to mark a slot as failed if the updated
+system does not boot successfully.
diff --git a/board/pc-efibootguard/genimage.cfg b/board/pc-efibootguard/genimage.cfg
new file mode 100644
index 0000000000..2437a89b63
--- /dev/null
+++ b/board/pc-efibootguard/genimage.cfg
@@ -0,0 +1,59 @@
+image EFI.vfat {
+ vfat {
+ file EFI/BOOT/BOOTX64.EFI {
+ image = "efibootguard/efibootguardx64.efi"
+ }
+ }
+
+ size = 16352K # 16MB - 32KB
+}
+
+image boot-a.vfat {
+ vfat {}
+
+ size = 128M
+ srcpath = "output/images/boot-a-part"
+}
+
+# # boot-b is a placeholder
+image boot-b.vfat {
+ vfat {}
+
+ size = 128M
+ srcpath = "output/images/boot-b-part"
+}
+
+image disk.img {
+ hdimage {
+ partition-table-type = "gpt"
+ }
+
+ partition EFI {
+ image = "EFI.vfat"
+ partition-type-uuid = esp
+ offset = 32K
+ bootable = true
+ }
+
+ partition boot-a {
+ partition-type-uuid = fat32
+ image = "boot-a.vfat"
+ }
+
+ partition boot-b {
+ partition-type-uuid = fat32
+ image = "boot-b.vfat"
+ }
+
+ partition system-a {
+ partition-type-uuid = root-x86-64
+ image = "rootfs.ext4"
+ size = 2G
+ }
+
+ # system-b is a placeholder
+ partition system-b {
+ partition-type-uuid = root-x86-64
+ size = 2G
+ }
+}
diff --git a/board/pc-efibootguard/linux.fragment b/board/pc-efibootguard/linux.fragment
new file mode 100644
index 0000000000..f9f2c3fd06
--- /dev/null
+++ b/board/pc-efibootguard/linux.fragment
@@ -0,0 +1,15 @@
+# efistub
+CONFIG_EFI=y
+CONFIG_EFI_STUB=y
+CONFIG_EFIVAR_FS=y
+CONFIG_EFI_PARTITION=y
+
+# efibootguard tools (bg_printenv / bg_setenv) use fat partition
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_EFI_PARTITION=y
+CONFIG_FAT_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NLS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
diff --git a/board/pc-efibootguard/post-build.sh b/board/pc-efibootguard/post-build.sh
new file mode 100755
index 0000000000..4f3e3254d8
--- /dev/null
+++ b/board/pc-efibootguard/post-build.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+set -e
+
+# Kernel cmdline to append
+KERNEL_CMDLINE=""
+
+# Create efibootguard boot-a slot configuration
+mkdir -p "${BINARIES_DIR}"/boot-a-part
+printf "boot-a" | iconv -f ascii -t UTF-16LE > "${BINARIES_DIR}"/boot-a-part/EFILABEL
+"${HOST_DIR}"/bin/bg_setenv \
+ --verbose \
+ --watchdog=0 \
+ --filepath="${BINARIES_DIR}"/boot-a-part/BGENV.DAT \
+ --revision=2 \
+ --ustate=OK \
+ --kernel="C:boot-a:bzImage" \
+ --args="root=PARTLABEL=system-a $KERNEL_CMDLINE"
+
+# Create efibootguard boot-a slot configuration (unbootable)
+mkdir -p "${BINARIES_DIR}"/boot-b-part
+printf "boot-b" | iconv -f ascii -t UTF-16LE > "${BINARIES_DIR}"/boot-b-part/EFILABEL
+"${HOST_DIR}"/bin/bg_setenv \
+ --verbose \
+ --watchdog=0 \
+ --filepath="${BINARIES_DIR}"/boot-b-part/BGENV.DAT \
+ --revision=1 \
+ --ustate=FAILED \
+ --kernel="C:boot-b:bzImage" \
+ --args="root=PARTLABEL=system-b $KERNEL_CMDLINE"
+
+# Copy kernel into boot-a.
+cp "${BINARIES_DIR}"/bzImage "${BINARIES_DIR}"/boot-a-part/
diff --git a/board/pc-efibootguard/post-image.sh b/board/pc-efibootguard/post-image.sh
new file mode 100755
index 0000000000..eec88f707d
--- /dev/null
+++ b/board/pc-efibootguard/post-image.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+set -e
+
+UUID=$(dumpe2fs "$BINARIES_DIR/rootfs.ext2" 2>/dev/null | sed -n 's/^Filesystem UUID: *\(.*\)/\1/p')
+sed "s/UUID_TMP/$UUID/g" board/pc-efibootguard/genimage.cfg > "$BINARIES_DIR/genimage.cfg"
+support/scripts/genimage.sh -c "$BINARIES_DIR/genimage.cfg"
diff --git a/board/pc-efibootguard/run-image-qemu.sh b/board/pc-efibootguard/run-image-qemu.sh
new file mode 100755
index 0000000000..32be727c3e
--- /dev/null
+++ b/board/pc-efibootguard/run-image-qemu.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+qemu-system-x86_64 \
+ -M pc \
+ -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
+ -drive file=output/images/disk.img,if=virtio,format=raw \
+ -boot menu=on \
+ -net nic,model=virtio \
+ -net user
diff --git a/configs/pc_x86_64_efibootguard_defconfig b/configs/pc_x86_64_efibootguard_defconfig
new file mode 100644
index 0000000000..7220b2d7ce
--- /dev/null
+++ b/configs/pc_x86_64_efibootguard_defconfig
@@ -0,0 +1,51 @@
+BR2_x86_64=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12=y
+BR2_GLOBAL_PATCH_DIR="board/pc/patches"
+BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="tty1"
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/pc-efibootguard/post-build.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/pc-efibootguard/post-image.sh"
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.47"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/pc/linux.config"
+BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/pc-efibootguard/linux.fragment"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
+BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
+BR2_PACKAGE_LINUX_FIRMWARE=y
+BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_9170=y
+BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_9271=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_3160=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_3168=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_5000=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_6000G2A=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_6000G2B=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_7260=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_7265D=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_8000C=y
+BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_8265=y
+BR2_PACKAGE_LINUX_FIRMWARE_RALINK_RT73=y
+BR2_PACKAGE_LINUX_FIRMWARE_RALINK_RT2XX=y
+BR2_PACKAGE_LINUX_FIRMWARE_RTL_81XX=y
+BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX=y
+BR2_PACKAGE_LINUX_FIRMWARE_RTL_88XX=y
+BR2_PACKAGE_LINUX_FIRMWARE_RTL_8169=y
+BR2_PACKAGE_ACPID=y
+BR2_PACKAGE_CONNMAN=y
+BR2_PACKAGE_CONNMAN_WIFI=y
+BR2_PACKAGE_CONNMAN_CLIENT=y
+BR2_PACKAGE_WIRELESS_REGDB=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
+# BR2_TARGET_ROOTFS_TAR is not set
+BR2_TARGET_EFIBOOTGUARD=y
+BR2_TARGET_EFIBOOTGUARD_X86_64=y
+BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS=y
+BR2_TARGET_HOST_EFIBOOTGUARD=y
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y

--
2.53.0

[Thomas Perale]

Hi Christopher,

In reply of:

> This patch adds a new boot package to Buildroot to build the
> EFI Boot Guard bootloader from the https://github.com/siemens/efibootguard
> repository.

Just a small comment as I see that simens/efibootguard has a GHSA assigned with
a CVE associated:

- https://github.com/siemens/efibootguard/security/advisories/GHSA-j6pp-7g99-24m7
- https://nvd.nist.gov/vuln/detail/CVE-2023-39950

With the CPE ID `siemens:efibootguard`.

> diff --git a/boot/efibootguard/efibootguard.mk b/boot/efibootguard/efibootguard.mk
> new file mode 100644
> index 0000000000..c40cef13ac
> --- /dev/null
> +++ b/boot/efibootguard/efibootguard.mk
> @@ -0,0 +1,60 @@
> +################################################################################
> +#
> +# efibootguard
> +#
> +################################################################################
> +
> +EFIBOOTGUARD_VERSION = 0.22
> +EFIBOOTGUARD_SITE = $(call github,siemens,efibootguard,refs/tags/v$(EFIBOOTGUARD_VERSION))
> +EFIBOOTGUARD_LICENSE = GPL-2.0-only
> +EFIBOOTGUARD_LICENSE_FILES = COPYING
> +

Add the following entry:

EFIBOOTGUARD_CPE_ID_VENDOR = siemens

Best regards,
PERALE Thomas

[Arnout Vandecappelle]

Hi Christopher,

On 24/05/2026 19:23, Christopher Obbard wrote:
> This patch adds a new boot package to Buildroot to build the
> EFI Boot Guard bootloader from the https://github.com/siemens/efibootguard
> repository.
>
> EFI Boot Guard can be chainloaded as an EFI application or used as a
> standalone bootloader and can be useful when booting A/B systems.
>
> Add a recipe to build the EFI bootloader application, user-space
> tooling & host tooling (both of which are used to manage EFI Boot Guard
> configuration).
>
> EFI Boot Guard can be built for multiple architectures, but this initial
> patch only builds the EFI bootloader for x86_64.

Any particular reason for that? With utils/test-pkg it should be easy enough
to test if all the architectures indeed work (or at least build).

> Signed-off-by: Christopher Obbard <obb...@gmail.com>
[snip]

> diff --git a/boot/efibootguard/Config.in b/boot/efibootguard/Config.in
> new file mode 100644
> index 0000000000..47fd478e8b
> --- /dev/null
> +++ b/boot/efibootguard/Config.in
> @@ -0,0 +1,37 @@
> +config BR2_TARGET_EFIBOOTGUARD_ARCH_SUPPORTS
> + bool
> + default y if BR2_x86_64

Is there actually platform-specific code in efibootguard? I had a very quick
look and couldn't find anything right away. But of course, it requires a
watchdog, and all the mentioned watchdog drivers are x86-specific AFAIK.

> + depends on BR2_USE_MMU

Where does the MMU dependency come from? Is it just copied from gnu-efi? If
so, it's better to use

depends on BR2_PACKAGE_GNU_EFI_ARCH_SUPPORTS

It's probably better to do that anyway, we like to make sure that for every
select there is a corresponding depends on for its dependencies.

> +
> +config BR2_TARGET_EFIBOOTGUARD
> + bool "efibootguard"
> + depends on BR2_TARGET_EFIBOOTGUARD_ARCH_SUPPORTS
> + depends on BR2_USE_WCHAR
> + select BR2_PACKAGE_GNU_EFI
> + select BR2_PACKAGE_PCIUTILS if BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS

This select should move to the BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS option
itself.

> + help
> + EFI Boot Guard is a UEFI bootloader intended for robust
> + A/B style updates. It arms a hardware watchdog before
> + handing over control to the OS and supports a fail-safe
> + boot mechanism to roll back if a boot attempt fails.
> +
> + https://github.com/siemens/efibootguard
> +
> +if BR2_TARGET_EFIBOOTGUARD
> +
> +config BR2_TARGET_EFIBOOTGUARD_X86_64
> + bool "x86-64"
> + depends on BR2_x86_64
> + help
> + Select this option if the platform you're targeting has a
> + 64 bits EFI BIOS.

I don't see why such an option should be user-selectable. The target
architecture is sufficient, no? In addition, it is not even used in the .mk file...

For the host package, there is no dependency on host-pciutils (which doesn't
exist anyway) but otherwise the options are the same. Is the pciutils dependency
perhaps optional?

> +EFIBOOTGUARD_INSTALL_TARGET = YES
> +else
> +EFIBOOTGUARD_INSTALL_TARGET = NO
> +endif
> +
> +EFIBOOTGUARD_INSTALL_IMAGES = YES
> +
> +EFIBOOTGUARD_AUTORECONF = YES
> +
> +EFIBOOTGUARD_AUTORECONF_OPTS = \
> + -I $(HOST_DIR)/share/autoconf-archive
> +
> +EFIBOOTGUARD_CONF_OPTS = \
> + --with-gnuefi-sys-dir=$(STAGING_DIR) \
> + --with-gnuefi-include-dir=$(STAGING_DIR)/usr/include/efi \
> + --with-gnuefi-lib-dir=$(STAGING_DIR)/usr/lib \
> + --disable-completion \
> + --disable-tests
> +
> +# TODO: Perhaps take inspiration from Debian patch https://salsa.debian.org/debian/efibootguard/-/blob/master/debian/patches/always-override-stack-protector-variables-in-EFI-bui.patch?ref_type=heads

Although that is a good patch (at first sight), it's something that should be
upstream, and anyway has no relationship with the -no-pie. So I'd just remove
this comment.

> +EFIBOOTGUARD_CONF_ENV = \
> + LDFLAGS="$(LDFLAGS) -no-pie"
> +
> +define EFIBOOTGUARD_INSTALL_IMAGES_CMDS
> + $(INSTALL) -d $(BINARIES_DIR)/efibootguard
> + $(INSTALL) -m 0644 $(@D)/efibootguardx64.efi $(BINARIES_DIR)/efibootguard/

Why in a subdirectory and not directly in BINARIES_DIR?

Regards,
Arnout

[Arnout Vandecappelle]

On 24/05/2026 19:23, Christopher Obbard wrote:

> Add an example recipe (based on configs/pc_x86_64_efi_defconfig) to
> generate an x86-64 image which boots the system using the EFI Boot Guard
> bootloader. The recipe is an example of how to create an image using
> EFI Boot Guard, including how to create the disk image & how to configure
> the bootloader.
>
> The created example image contains two boot slots; one of which contains
> the environment built by Buildroot and the other is an empty, dummy slot
> (e.g. cannot be booted from).
>
> EFI Boot Guard provides a tool for generating UKI images, which can then
> be signed for Secure Boot. For simplicity, this is not enabled in the
> example recipe.

I think it would be useful to include this as well. Of course that requires
knowing how to enroll your own key but I guess that can be left as an exercise
for the reader :-)

All other readme's are called readme.txt. We have no markdown files at all at
the moment, except for SECURITY.md which is mandated to be markdown.

> @@ -0,0 +1,89 @@
> +# EFI Boot Guard Example Recipe
> +
> +This recipe creates a basic x86 disk image using [EFI Boot Guard](https://github.com/siemens/efibootguard/tree/master)
> +as the bootloader with two root filesystem slots.
> +
> +The image is intended to demonstrate a typical A/B boot layout. The first slot is
> +populated with the root filesystem generated as part of the Buildroot build,
> +while the second slot is left empty so that it can be used later by an update
> +tool, which is out-of-scope for this example recipe.
> +
> +The recipe also creates the EFI system partition and installs the EFI Boot Guard
> +bootloader components needed to select and boot one of the available slots. Each
> +slot has its own EFI Boot Guard environment, containing the kernel image and
> +configuration.
> +
> +This example is deliberately minimal. It is intended as a reference for users who
> +want to integrate EFI Boot Guard into their own platform-specific images, rather
> +than as a complete production-ready update setup.
> +
> +This recipe was designed to be ran in QEMU and may need additional changes to run
> +on real hardware.

But you did test it on real hardware, right? Can't you copy the instructions
from board/pc/readme.txt on how to boot on real hardware?

Since this is a demo defconfig, perhaps it would make sense to include RAUC as
well?

> diff --git a/board/pc-efibootguard/genimage.cfg b/board/pc-efibootguard/genimage.cfg
> new file mode 100644
> index 0000000000..2437a89b63
> --- /dev/null
> +++ b/board/pc-efibootguard/genimage.cfg
> @@ -0,0 +1,59 @@
> +image EFI.vfat {
> + vfat {
> + file EFI/BOOT/BOOTX64.EFI {
> + image = "efibootguard/efibootguardx64.efi"
> + }
> + }
> +
> + size = 16352K # 16MB - 32KB
> +}
> +
> +image boot-a.vfat {
> + vfat {}

Does it have to be a FAT partition? Seems a bit... unsafe...

> +
> + size = 128M

That seems quite large for just a kernel. Unlike /boot in a typical distro, it
will always contain just a single kernel, right?

That seems _extremely_ large... Remember, that size also means that if you dd
the image you have to write all of it. It's better when you use bmaptool, but we
don't do that by default.

boot-b?

> +mkdir -p "${BINARIES_DIR}"/boot-b-part
> +printf "boot-b" | iconv -f ascii -t UTF-16LE > "${BINARIES_DIR}"/boot-b-part/EFILABEL
> +"${HOST_DIR}"/bin/bg_setenv \
> + --verbose \
> + --watchdog=0 \
> + --filepath="${BINARIES_DIR}"/boot-b-part/BGENV.DAT \
> + --revision=1 \
> + --ustate=FAILED \
> + --kernel="C:boot-b:bzImage" \
> + --args="root=PARTLABEL=system-b $KERNEL_CMDLINE"
> +
> +# Copy kernel into boot-a.
> +cp "${BINARIES_DIR}"/bzImage "${BINARIES_DIR}"/boot-a-part/

I think it makes more sense to do all of the above in post-image as well.
post-build is meant for manipulations of TARGET_DIR.

> diff --git a/board/pc-efibootguard/post-image.sh b/board/pc-efibootguard/post-image.sh
> new file mode 100755
> index 0000000000..eec88f707d
> --- /dev/null
> +++ b/board/pc-efibootguard/post-image.sh
> @@ -0,0 +1,7 @@
> +#!/bin/sh
> +
> +set -e
> +
> +UUID=$(dumpe2fs "$BINARIES_DIR/rootfs.ext2" 2>/dev/null | sed -n 's/^Filesystem UUID: *\(.*\)/\1/p')
> +sed "s/UUID_TMP/$UUID/g" board/pc-efibootguard/genimage.cfg > "$BINARIES_DIR/genimage.cfg"

There is no UUID_TMP in that file...

> +support/scripts/genimage.sh -c "$BINARIES_DIR/genimage.cfg"
> diff --git a/board/pc-efibootguard/run-image-qemu.sh b/board/pc-efibootguard/run-image-qemu.sh
> new file mode 100755
> index 0000000000..32be727c3e
> --- /dev/null
> +++ b/board/pc-efibootguard/run-image-qemu.sh
> @@ -0,0 +1,9 @@
> +#!/bin/sh
> +
> +qemu-system-x86_64 \
> + -M pc \
> + -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
> + -drive file=output/images/disk.img,if=virtio,format=raw \
> + -boot menu=on \
> + -net nic,model=virtio \
> + -net user

We don't usually have such a script, it's just part of the readme.txt.

> diff --git a/configs/pc_x86_64_efibootguard_defconfig b/configs/pc_x86_64_efibootguard_defconfig
> new file mode 100644
> index 0000000000..7220b2d7ce
> --- /dev/null
> +++ b/configs/pc_x86_64_efibootguard_defconfig
> @@ -0,0 +1,51 @@
> +BR2_x86_64=y
> +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12=y

We expect new and updated defconfigs to switch to the Bootlin glibc stable
toolchain (if appropriate) in order to limit build time. This is unfortunately
still undocumented, except for the report of the meeting where it was decided [1].

> +BR2_GLOBAL_PATCH_DIR="board/pc/patches"
> +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
> +BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
> +BR2_TARGET_GENERIC_GETTY_PORT="tty1"
> +BR2_ROOTFS_POST_BUILD_SCRIPT="board/pc-efibootguard/post-build.sh"
> +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/pc-efibootguard/post-image.sh"
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.47"

You can use 6.18.33 now.


Regards,
Arnout

[1] https://elinux.org/Buildroot:DeveloperDaysELCE2024#Rules_for_defconfigs

[Christopher Obbard]

Hi Thomas,

Thank you for your comment. I have added EFIBOOTGUARD_CPE_ID_VENDOR to
the next revision.


Cheers!

Chris

[Christopher Obbard]

Hi Arnout,

Thank you for your review.

On Tue, 26 May 2026 at 20:37, Arnout Vandecappelle <arn...@rnout.be> wrote:
> On 24/05/2026 19:23, Christopher Obbard wrote:
> > This patch adds a new boot package to Buildroot to build the
> > EFI Boot Guard bootloader from the https://github.com/siemens/efibootguard
> > repository.
> >
> > EFI Boot Guard can be chainloaded as an EFI application or used as a
> > standalone bootloader and can be useful when booting A/B systems.
> >
> > Add a recipe to build the EFI bootloader application, user-space
> > tooling & host tooling (both of which are used to manage EFI Boot Guard
> > configuration).
> >
> > EFI Boot Guard can be built for multiple architectures, but this initial
> > patch only builds the EFI bootloader for x86_64.
>
> Any particular reason for that? With utils/test-pkg it should be easy enough
> to test if all the architectures indeed work (or at least build).

Thanks; I have now modified the recipe such that it builds for all (supported!)
architectures and now installs the binaries in the right place.

> > Signed-off-by: Christopher Obbard <obb...@gmail.com>
> [snip]
> > diff --git a/boot/efibootguard/Config.in b/boot/efibootguard/Config.in
> > new file mode 100644
> > index 0000000000..47fd478e8b
> > --- /dev/null
> > +++ b/boot/efibootguard/Config.in
> > @@ -0,0 +1,37 @@
> > +config BR2_TARGET_EFIBOOTGUARD_ARCH_SUPPORTS
> > + bool
> > + default y if BR2_x86_64
>
> Is there actually platform-specific code in efibootguard? I had a very quick
> look and couldn't find anything right away. But of course, it requires a
> watchdog, and all the mentioned watchdog drivers are x86-specific AFAIK.

I modified the recipe to be much more generic for different arches now.

> > + depends on BR2_USE_MMU
>
> Where does the MMU dependency come from? Is it just copied from gnu-efi? If
> so, it's better to use
>
> depends on BR2_PACKAGE_GNU_EFI_ARCH_SUPPORTS
>
> It's probably better to do that anyway, we like to make sure that for every
> select there is a corresponding depends on for its dependencies.

Thanks, that makes a lot of sense!

> > +
> > +config BR2_TARGET_EFIBOOTGUARD
> > + bool "efibootguard"
> > + depends on BR2_TARGET_EFIBOOTGUARD_ARCH_SUPPORTS
> > + depends on BR2_USE_WCHAR
> > + select BR2_PACKAGE_GNU_EFI
> > + select BR2_PACKAGE_PCIUTILS if BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS
>
> This select should move to the BR2_TARGET_EFIBOOTGUARD_INSTALL_TOOLS option
> itself.

No, I found that pciutils is needed for the EFI bootload itself. I've
modified it now.

> > + help
> > + EFI Boot Guard is a UEFI bootloader intended for robust
> > + A/B style updates. It arms a hardware watchdog before
> > + handing over control to the OS and supports a fail-safe
> > + boot mechanism to roll back if a boot attempt fails.
> > +
> > + https://github.com/siemens/efibootguard
> > +
> > +if BR2_TARGET_EFIBOOTGUARD
> > +
> > +config BR2_TARGET_EFIBOOTGUARD_X86_64
> > + bool "x86-64"
> > + depends on BR2_x86_64
> > + help
> > + Select this option if the platform you're targeting has a
> > + 64 bits EFI BIOS.
>
> I don't see why such an option should be user-selectable. The target
> architecture is sufficient, no? In addition, it is not even used in the .mk file...

Thanks, I removed that useless option.

It's needed for the bootloader. I cleaned it up a bit.

> > +EFIBOOTGUARD_INSTALL_TARGET = YES
> > +else
> > +EFIBOOTGUARD_INSTALL_TARGET = NO
> > +endif
> > +
> > +EFIBOOTGUARD_INSTALL_IMAGES = YES
> > +
> > +EFIBOOTGUARD_AUTORECONF = YES
> > +
> > +EFIBOOTGUARD_AUTORECONF_OPTS = \
> > + -I $(HOST_DIR)/share/autoconf-archive
> > +
> > +EFIBOOTGUARD_CONF_OPTS = \
> > + --with-gnuefi-sys-dir=$(STAGING_DIR) \
> > + --with-gnuefi-include-dir=$(STAGING_DIR)/usr/include/efi \
> > + --with-gnuefi-lib-dir=$(STAGING_DIR)/usr/lib \
> > + --disable-completion \
> > + --disable-tests
> > +
> > +# TODO: Perhaps take inspiration from Debian patch https://salsa.debian.org/debian/efibootguard/-/blob/master/debian/patches/always-override-stack-protector-variables-in-EFI-bui.patch?ref_type=heads
>
> Although that is a good patch (at first sight), it's something that should be
> upstream, and anyway has no relationship with the -no-pie. So I'd just remove
> this comment.

Thanks, I removed it.

> > +EFIBOOTGUARD_CONF_ENV = \
> > + LDFLAGS="$(LDFLAGS) -no-pie"
> > +
> > +define EFIBOOTGUARD_INSTALL_IMAGES_CMDS
> > + $(INSTALL) -d $(BINARIES_DIR)/efibootguard
> > + $(INSTALL) -m 0644 $(@D)/efibootguardx64.efi $(BINARIES_DIR)/efibootguard/
>
> Why in a subdirectory and not directly in BINARIES_DIR?

Thanks; I moved it to BINARIES_DIR.


Cheers!

Chris

[Christopher Obbard]

Hi Arnout,

On Tue, 26 May 2026 at 21:09, Arnout Vandecappelle <arn...@rnout.be> wrote:
> On 24/05/2026 19:23, Christopher Obbard wrote:
> > Add an example recipe (based on configs/pc_x86_64_efi_defconfig) to
> > generate an x86-64 image which boots the system using the EFI Boot Guard
> > bootloader. The recipe is an example of how to create an image using
> > EFI Boot Guard, including how to create the disk image & how to configure
> > the bootloader.
> >
> > The created example image contains two boot slots; one of which contains
> > the environment built by Buildroot and the other is an empty, dummy slot
> > (e.g. cannot be booted from).
> >
> > EFI Boot Guard provides a tool for generating UKI images, which can then
> > be signed for Secure Boot. For simplicity, this is not enabled in the
> > example recipe.
>
> I think it would be useful to include this as well. Of course that requires
> knowing how to enroll your own key but I guess that can be left as an exercise
> for the reader :-)

Makes sense! I will add instructions to generate a certificate and
sign the images in the next version.

Thanks; I've modified the readme file now to match the others in the tree.

> > @@ -0,0 +1,89 @@
> > +# EFI Boot Guard Example Recipe
> > +
> > +This recipe creates a basic x86 disk image using [EFI Boot Guard](https://github.com/siemens/efibootguard/tree/master)
> > +as the bootloader with two root filesystem slots.
> > +
> > +The image is intended to demonstrate a typical A/B boot layout. The first slot is
> > +populated with the root filesystem generated as part of the Buildroot build,
> > +while the second slot is left empty so that it can be used later by an update
> > +tool, which is out-of-scope for this example recipe.
> > +
> > +The recipe also creates the EFI system partition and installs the EFI Boot Guard
> > +bootloader components needed to select and boot one of the available slots. Each
> > +slot has its own EFI Boot Guard environment, containing the kernel image and
> > +configuration.
> > +
> > +This example is deliberately minimal. It is intended as a reference for users who
> > +want to integrate EFI Boot Guard into their own platform-specific images, rather
> > +than as a complete production-ready update setup.
> > +
> > +This recipe was designed to be ran in QEMU and may need additional changes to run
> > +on real hardware.
>
> But you did test it on real hardware, right? Can't you copy the instructions
> from board/pc/readme.txt on how to boot on real hardware?

Sure; I will do that.

Unfortunately the RAUC integration for EFI Boot Guard is still waiting
for upstream review: https://github.com/rauc/rauc/pull/1450
I've got another buildroot patch series to integrate RAUC into this
recipe; but I'd rather send that as a follow-up once the upstream PR
is a bit further.
If you're interested the recipe (it's a standalone recipe but I will
rework it to be part of this recipe) is at
https://github.com/obbardc/buildroot/tree/wip/obbardc/rauc-efibootguard
I don't think installing RAUC is useful until the PR is merged, personally.

> > diff --git a/board/pc-efibootguard/genimage.cfg b/board/pc-efibootguard/genimage.cfg
> > new file mode 100644
> > index 0000000000..2437a89b63
> > --- /dev/null
> > +++ b/board/pc-efibootguard/genimage.cfg
> > @@ -0,0 +1,59 @@
> > +image EFI.vfat {
> > + vfat {
> > + file EFI/BOOT/BOOTX64.EFI {
> > + image = "efibootguard/efibootguardx64.efi"
> > + }
> > + }
> > +
> > + size = 16352K # 16MB - 32KB
> > +}
> > +
> > +image boot-a.vfat {
> > + vfat {}
>
> Does it have to be a FAT partition? Seems a bit... unsafe...

Yeah, unfortunately the EFI Boot Guard configuration partitions have
to be FAT. It's probably due to EFI environment not supporting many
filesystems?
If it's any help, the config partitions are not supposed to be mounted
RW during normal boot and only mounted when modified with the
userspace tooling.

> > +
> > + size = 128M
>
> That seems quite large for just a kernel. Unlike /boot in a typical distro, it
> will always contain just a single kernel, right?

Yes, I agree. It was leftover from the project this was taken from. I
will reduce the size of /boot.

Yes, I agree. Again, this is a leftover from the project this recipe
was taken from. I will reduce the size.

Thanks, changed.

> > +mkdir -p "${BINARIES_DIR}"/boot-b-part
> > +printf "boot-b" | iconv -f ascii -t UTF-16LE > "${BINARIES_DIR}"/boot-b-part/EFILABEL
> > +"${HOST_DIR}"/bin/bg_setenv \
> > + --verbose \
> > + --watchdog=0 \
> > + --filepath="${BINARIES_DIR}"/boot-b-part/BGENV.DAT \
> > + --revision=1 \
> > + --ustate=FAILED \
> > + --kernel="C:boot-b:bzImage" \
> > + --args="root=PARTLABEL=system-b $KERNEL_CMDLINE"
> > +
> > +# Copy kernel into boot-a.
> > +cp "${BINARIES_DIR}"/bzImage "${BINARIES_DIR}"/boot-a-part/
>
> I think it makes more sense to do all of the above in post-image as well.
> post-build is meant for manipulations of TARGET_DIR.

Do you mean move it into post-image instead of post-build? Your
reasoning makes sense to me.

> > diff --git a/board/pc-efibootguard/post-image.sh b/board/pc-efibootguard/post-image.sh
> > new file mode 100755
> > index 0000000000..eec88f707d
> > --- /dev/null
> > +++ b/board/pc-efibootguard/post-image.sh
> > @@ -0,0 +1,7 @@
> > +#!/bin/sh
> > +
> > +set -e
> > +
> > +UUID=$(dumpe2fs "$BINARIES_DIR/rootfs.ext2" 2>/dev/null | sed -n 's/^Filesystem UUID: *\(.*\)/\1/p')
> > +sed "s/UUID_TMP/$UUID/g" board/pc-efibootguard/genimage.cfg > "$BINARIES_DIR/genimage.cfg"
>
> There is no UUID_TMP in that file...

Thanks; that was leftover from the project this came from. Removed.

> > +support/scripts/genimage.sh -c "$BINARIES_DIR/genimage.cfg"
> > diff --git a/board/pc-efibootguard/run-image-qemu.sh b/board/pc-efibootguard/run-image-qemu.sh
> > new file mode 100755
> > index 0000000000..32be727c3e
> > --- /dev/null
> > +++ b/board/pc-efibootguard/run-image-qemu.sh
> > @@ -0,0 +1,9 @@
> > +#!/bin/sh
> > +
> > +qemu-system-x86_64 \
> > + -M pc \
> > + -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
> > + -drive file=output/images/disk.img,if=virtio,format=raw \
> > + -boot menu=on \
> > + -net nic,model=virtio \
> > + -net user
>
> We don't usually have such a script, it's just part of the readme.txt.

Thanks; removed the script and put it in the readme.txt file.

> > diff --git a/configs/pc_x86_64_efibootguard_defconfig b/configs/pc_x86_64_efibootguard_defconfig
> > new file mode 100644
> > index 0000000000..7220b2d7ce
> > --- /dev/null
> > +++ b/configs/pc_x86_64_efibootguard_defconfig
> > @@ -0,0 +1,51 @@
> > +BR2_x86_64=y
> > +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12=y
>
> We expect new and updated defconfigs to switch to the Bootlin glibc stable
> toolchain (if appropriate) in order to limit build time. This is unfortunately
> still undocumented, except for the report of the meeting where it was decided [1].

Thanks; I will modify that in the next version.

> > +BR2_GLOBAL_PATCH_DIR="board/pc/patches"
> > +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
> > +BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
> > +BR2_TARGET_GENERIC_GETTY_PORT="tty1"
> > +BR2_ROOTFS_POST_BUILD_SCRIPT="board/pc-efibootguard/post-build.sh"
> > +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/pc-efibootguard/post-image.sh"
> > +BR2_LINUX_KERNEL=y
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.47"
>
> You can use 6.18.33 now.

Thanks; I will modify that in the next version.


Cheers!

Chris

[Jan Kiszka]

On 09.06.26 00:49, Christopher Obbard wrote:
>>> diff --git a/board/pc-efibootguard/genimage.cfg b/board/pc-efibootguard/genimage.cfg
>>> new file mode 100644
>>> index 0000000000..2437a89b63
>>> --- /dev/null
>>> +++ b/board/pc-efibootguard/genimage.cfg
>>> @@ -0,0 +1,59 @@
>>> +image EFI.vfat {
>>> + vfat {
>>> + file EFI/BOOT/BOOTX64.EFI {
>>> + image = "efibootguard/efibootguardx64.efi"
>>> + }
>>> + }
>>> +
>>> + size = 16352K # 16MB - 32KB
>>> +}
>>> +
>>> +image boot-a.vfat {
>>> + vfat {}
>>
>> Does it have to be a FAT partition? Seems a bit... unsafe...
>
> Yeah, unfortunately the EFI Boot Guard configuration partitions have
> to be FAT. It's probably due to EFI environment not supporting many
> filesystems?

Exactly. FAT is the only driver you can expect from a random EFI firmware.

> If it's any help, the config partitions are not supposed to be mounted
> RW during normal boot and only mounted when modified with the
> userspace tooling.

...which happens during regular updates e.g.

>
>
>>> +
>>> + size = 128M
>>
>> That seems quite large for just a kernel. Unlike /boot in a typical distro, it
>> will always contain just a single kernel, right?
>
> Yes, I agree. It was leftover from the project this was taken from. I
> will reduce the size of /boot.
>

Depends. If this is a UKI (Unified Kernel Image, required for secure
boot), then it's more than just the kernel. If it needs to be 128M
depends on the concrete project configuration of course.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center