Ard Biesheuvel <[email protected]> writes: > On Sat, 4 Apr 2020 at 12:50, Heinrich Schuchardt <[email protected]> wrote: >> >> On 4/4/20 11:57 AM, François Ozog wrote: >> > Hi, >> > >> > I instrumented boot on my Ubuntu 18.04 server right after systemd startup >> > and caught an access to: >> > /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f >> >> Jeremy's patch 06f7d4a1618d ("efibc: Add EFI Bootloader Control module") >> introduced the variable though this change seems to be unrelated to the >> commit message. See efibc_set_variable() in drivers/firmware/efi/efibc.c.
This patch touch the LoaderEntryRebootReason and LoaderEntryOneShot EFI variables. efibc does not touch the LoaderDevicePartUUID variable. These two variables are only touched when CONFIG_EFI_BOOTLOADER_CONTROL=y and only during the reboot sequence not during startup. >> @Jeremy, Ard >> Why is this variable written when CONFIG_EFI_BOOTLOADER_CONTROL=y? It >> seems not be related to the description of the customizing setting. This is a good question as looking at the efibc code I don't see this variable being touched. >> According to the UEFI spec the SetVariable() service is optional at >> run-time. >> >> I have started work on implementing variable services at run-time in >> U-Boot. See https://lists.denx.de/pipermail/u-boot/2020-March/404441.html. >> > > The whole EFI bootloader control thing predates my EFI maintainership. > I did find some discussions around it, and it seems like Matt simply > merged to put an end to the discussion, rather than because he was > convinced it was a good idea. I would of course disagree, it was not an argument where the maintainer just gave up. I unfortunately can't find this discussion either but the whole idea is to provide a way to propagate the reboot reason and target from the reboot system call to the boot loader. We had many discussions about whether or not it should be handled at the userspace level only and came up to the conclusion that it is unfortunately not always possible to handle this from the userspace level. We intended to publish more variables which we have removed during our discussion with Matt to prevent the creation of an ABI between Kernel and bootloader. It has been kept very generic and limited to the two LoaderEntryRebootReason and LoaderEntryOneShot variables only. This feature has been particularly important for EFI Android platform for the reboot target is passed this way to the kernel and for which it was not possible to implement another solution. According to https://systemd.io/BOOT_LOADER_INTERFACE/ it looks like systemd has several variables using this same UUID. One of them is LoaderDevicePartUUID and the documentation of the variable make me think that it is written by the bootloader and read by systemd. ``The EFI variable LoaderDevicePartUUID contains the partition GUID of the ESP the boot loader was run from formatted as NUL-terminated UTF16 string, in normal GUID syntax.'' Regards, --Jeremy One Emacs to rule them all _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
