Hi, > This patch implements the LoaderDevicePartUUID part of the systemd boot > loader interface to pass data from the loader to the OS / systemd. The > data is passed via EFI variables which are set by the first-stage loader > (the one on the ESP), or alternatively by the first loader that is > executed. By that, userspace components can later inspect this variable > to e.g. limit the search for config partitions to the device it was > bootet from. Currently only the LoaderDevicePartUUID is implemented. > > Technically, the loader asks the EFI API for the UUID of the partition it > is executed from. Normally that is the ESP partition. Then, this UUID is > assigned to the LoaderDevicePartUUID EFI variable (in case not set yet).
Just a note: We deliberately decided *not* to base the state-keeping stuff on EFI variables back then due to their questionable robustness ― at least back then when EFI Boot Guard was initiated. If that is still true, we should be prepared to do proper decisions without this or find an other more robust place to store this information. If it's no longer true, then we may think about using EFI variables for more than this, e.g., also for other information currently stored in an ebgenv... > This logic is crucial to correctly support chain-loading uses-cases and > also aligned with how systemd boot implements this. > > For the sake of completeness, this logic is also added to the efi stub. > When using it in combination with the EBG loader, this is irrelevant, > but when starting the UKI directly it is needed. Kind regards, Christian -- Dr. Christian Storm Siemens AG, Technology, T CED SES-DE Otto-Hahn-Ring 6, 81739 München, Germany -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/612A5023-5836-40FC-8C27-95292C2417FF%40siemens.com.
