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
This led to: https://systemd.io/DISCOVERABLE_PARTITIONS/ And then: https://systemd.io/BOOT_LOADER_INTERFACE/ https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
My server is configured with Grub to boot (grub and kernel on a HD, root FS of NVME as grub do not have nvme driver for my card) but the udev is still checking those systemd-boot variables.
From a boot loader perspective, we have the following EFI applications:
- Grub2 - EFIBootGuard (used by CIP) - Systemd-boot (used by ?)
Regardless of the loader, I assume we need to ensure whatever option is selected by solution builders, they can implement it with our U-Boot reference implementation of UEFI.
The Systemd boot-bless seems of high interest for rolling back UEFI update capsules of firmware...
I'd be happy to get some feed back on : - the systemd-boot technology - whether we need to implement the above specs in our UEFI implementation - whether this has an influence on EBBR
Cheers
FF
PS: other references https://manpages.debian.org/testing/systemd/systemd-boot.7.en.html https://manpages.debian.org/testing/systemd/systemd-bless-boot.service.8.en.... http://man7.org/linux/man-pages/man1/bootctl.1.html
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.
@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.
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.
Best regards
Heinrich
This led to: https://systemd.io/DISCOVERABLE_PARTITIONS/ And then: https://systemd.io/BOOT_LOADER_INTERFACE/ https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
My server is configured with Grub to boot (grub and kernel on a HD, root FS of NVME as grub do not have nvme driver for my card) but the udev is still checking those systemd-boot variables.
From a boot loader perspective, we have the following EFI applications:
- Grub2
- EFIBootGuard (used by CIP)
- Systemd-boot (used by ?)
Regardless of the loader, I assume we need to ensure whatever option is selected by solution builders, they can implement it with our U-Boot reference implementation of UEFI.
The Systemd boot-bless seems of high interest for rolling back UEFI update capsules of firmware...
I'd be happy to get some feed back on :
- the systemd-boot technology
- whether we need to implement the above specs in our UEFI implementation
- whether this has an influence on EBBR
Cheers
FF
PS: other references https://manpages.debian.org/testing/systemd/systemd-boot.7.en.html https://manpages.debian.org/testing/systemd/systemd-bless-boot.service.8.en.... http://man7.org/linux/man-pages/man1/bootctl.1.html
On Sat, 4 Apr 2020 at 12:50, Heinrich Schuchardt xypron.glpk@gmx.de 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.
@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.
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.
Ard Biesheuvel ardb@kernel.org writes:
On Sat, 4 Apr 2020 at 12:50, Heinrich Schuchardt xypron.glpk@gmx.de 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@lists.linaro.org
-
Ard Biesheuvel -
François Ozog -
Heinrich Schuchardt -
jeremy.compostella＠intel.com