Re: EFI File renaming

[Traut Manuel LCPF-CH <Manuel.Traut@mt.com>]

> > > > systemd-boot counting logic requires [0] to be implemented.
> >
> > > > If not we plan to add the functionality in fs/fs.c and fs/fat - correct?
> > >
> > > We don't have plans for it, but explaining any use cases you have might help
> >
> > systemd-boot is able to do bootcounting by renaming the UKI image [0]
> > the code that triggers the not implemented code section is here [1].
> >
> > With this it is possible to have watchdog based A/B switching on systems
> > without a writeable u-boot environment. And therefore it is a nice
> > method to implement measured boot.
> 
> The A/B is ok, but I cant understand how that realted to measured
> boot. The TPM access, UKI infrastucture etc, will work fine without
> A/B

Yes, TPM, UKI works fine right now :)

systemd-boot is renaming the UKI before it starts it, by increasing
the bootcounter that is part of the filename. If the system is fully
booted the file gets renamed again to reset the bootcounter.

If the bootcounter exceeds systemd-boot tries the next UKI.
The UKIs can be signed and are still valid after rename.

I expect that changes to the u-boot env will change a PCR measurement.
At least it should be like this, since it might alter the boot path?

For trusted systems it would be nice to have a meaurement of the EFI
variables and beside that have no dynamic environment.

Hope this explenation is understandable?
Manuel

> > [0] https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting
> > [1] https://github.com/systemd/systemd/blob/3304a029b847e87da51f7a8ad8c118111508e009/src/boot/boot.c#L1407
> >
> > > >
> > > > [0] https://elixir.bootlin.com/u-boot/v2025.01-rc1/source/lib/efi_loader/efi_file.c#L971