Looking ahead: EFI Boot Guard "next generation"

[Jan Kiszka]

Hi all,

EFI Boot Guard (EBG) is now more than 9 years old. It grew up fairly
well so far, is used in many, many deployments, and that not only on our
side. To honor this, the next release of EBG will likely be "v1.0". This
will very likely not be different from what would have been "v0.23"
otherwise.

So, while EBG is basically working now, it is also carrying quite some
history and some oddities in design and implementation from its early
days. None of them were ever pressing enough to rework EBG from ground,
but we know that ground rework would benefit EBG and its users.

Therefore, I would like to finally start by drafting a vision of a next
generation EBG, maybe a "v2.0" one day. This vision was evolving
internally for a while, but now it's time do put it down, maybe start a
broader discussion or even some work on sub-tasks.

Key properties of EBG "next generation":

- BootNext-based A/B switching

Instead of using a single-point-of-failure EBG binary as bootloader,
we want to build the boot path switching and its USTATE on top of the
UEFI boot manager, Boot####, BootNext, and a custom UEFI variable to
track the full USTATE. Overcoming the bootloader will shorten the boot
path and avoid headaches whenever you may have to update this, because
a bug was found or some key rotation might be needed.

A first local prototype exists that implement this schema and works on
x86 at least, see "Revamped EBG library" below.

- Dual-ESP instead of EBG boot partitions

While the BootNext scheme would allow a single ESP as well, and EBG
may also support this as secondary mode, the preferred variant will
exploit that there can be multiple ESPs in a system. The boot manager
will help to select "A" or "B", and we continue to avoid having to
touch the currently active partition for preparing and testing an
update.

The primary content of these ESPs will then be a UKI. EBG will need no
additional files anymore.

- UKI-based watchdog drivers

With the EBG bootloader gone, we need a new home for the watchdog
drivers. Those are still needed to have a simple and robust way for
starting a hardware watchdog that Linux can take over once it is fully
operational. The timeout is defined via new UKI section and, thus,
configured while while assembling a UKI.

The UEFI watchdog of the boot services is unfortunately terminated too
early, when Linux ends them. When U-Boot (ARM, RISC-V etc.) or some
special firmware is used, such a watchdog may also be started earlier,
and the watchdog drivers of EBG are not needed.

A prototype for this watchdog mode exists locally. Goal is to maintain
the same driver structure as with EBG 1.0 so that the code bases can
be kept in sync as long as needed.

- Revamped EBG library and CLI tools

The new userland version will come with significantly simpler API,
dropping a lot of baggage from current EBG (e.g. uservars) that will
no longer be needed. CLI tools will solely work on top of a library
that implements this API, so will typical users like SWUpdate do.

A local prototype exists which is implemented in - you may guess it -
Rust. Needs more work, though, to fully realize this vision.

- In-field migration

Migration from current EBG to this new generation should be
facilitated with used-once helpers that identify the inactive B
partition, change its type to ESP, and support the new EBG library in
setting up the legacy EBG and its path A partition as "ESP A" while
Booting-Next into the "ESP B". The goal is not to carry logic for the
current data structures in the new code base forever, specifically not
in deployed binaries that work with the new schema.

Now the question his how to reach this and what needs to done for it.
Here is a list of tasks that are currently on my mind (not necessarily
in logical order):

- release v1.0, fork-off stable-v1.x from it, continue in master with
the new generation

- drop EBG bootloader, merge UKI-based watchdog driver mode

- bring new userland into codebase, dropping old libs and tools

- rework build system (cargo + x?)

- probably drop dependency on gnu-efi

- explore if BootNext and dual ESP work fine more (real) x86 hardware
and with U-Boot as EFI provider

- write SWUpdate support for new API

- plumb prototype together in isar-cip-core

- develop v1-migration path, write helpers and implement tests

- explore if a plugin concept for systemd's UKI stub is possible so that
watchdog drivers could also be used with that codebase (and ukify)

- release v2.0 once everything feels mature enough, specifically APIs

- continue to maintain v1.x for quite a while!

I hope I covered everything essential.

Note that there is no fixed timeline behind all of this. Even under
ideal conditions (full focus), it would easily several months to get
everything (including dependencies) into a usable prototype state. We
plan to work on this, but so far only as background activity. If anyone
sees a more urgent need and would like to support this, please reach out!

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center