efi/preinstall: Stop relying on BootCurrent#536
Merged
ernestl merged 2 commits intocanonical:masterfrom Apr 10, 2026
Merged
Conversation
The PCR4 and PCR7 checks were relying on the BootCurrent EFI variable to identify the EV_EFI_BOOT_SERVICES_APPLICATION event in the TCG log that corresponds to the launch of the initial OS loader. This is proving problematic on some systems: - Whilst some firmware populates a Boot variable containing a load option with a path matching the OS loader and sets BootCurrent to point to this when booting from removable media, some firmware implementations dosn't set a path that matches the OS loader, and this path doesn't match any event in the TCG log. - Some systems don't seem to have BootCurrent set at all when booting from removable media. Instead, assume that the first OS-present EV_EFI_BOOT_SERVICES_APPLICATION event that isn't Absolute is the initial OS loader. If it isn't, the PCR4 checks will fail as expected because os the mismsatched digest. We have to have a special case for Absolute here because some systems measure this launch as part of OS-present. This also makes the checks a bit more permissive where firmware bugs don't cause problems with generating profiles: - The PCR4 checks no longer enforce that there can be only one EV_OMIT_BOOT_DEVICE_EVENT event. - The PCR4 checks no longer enforce that there cannot be a EV_EFI_ACTION "Calling EFI Application from Boot Option" if there is a EV_OMIT_BOOT_DEVICE_EVENT event. We already don't enforce the existence of the EV_EFI_ACTION event if there is no EV_OMIT_BOOT_DEVICE_EVENT event even though it should be there, because we know that some firmware misbehaves here. - The PCR4 checks no longer gate the reading of the SysPrepOrder and SysPrep variables on the BootOptionSupport flags. Fixes: canonical#517 Fixes: canonical#519
…ariables in unit tests
valentindavid
approved these changes
Apr 10, 2026
|
when will this reach the installer? can't install ubuntu with fde on my x1 carbon |
|
Just adding a problem report, echoing the above:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The PCR4 and PCR7 checks were relying on the
BootCurrentEFI variable toidentify the
EV_EFI_BOOT_SERVICES_APPLICATIONevent in the TCG log thatcorresponds to the launch of the initial OS loader. This is proving
problematic on some systems:
option with a path matching the OS loader and sets
BootCurrenttopoint to this when booting from removable media, some firmware
implementations dosn't set a path that matches the OS loader, and this
path doesn't match any event in the TCG log.
BootCurrentset at all when bootingfrom removable media.
Instead, assume that the first OS-present
EV_EFI_BOOT_SERVICES_APPLICATIONevent that isn't Absolute is theinitial OS loader. If it isn't, the PCR4 checks will fail as expected
because os the mismsatched digest. We have to have a special case for
Absolute here because some systems measure this launch as part of
OS-present.
This also makes the checks a bit more permissive where firmware bugs
don't cause problems with generating profiles:
EV_OMIT_BOOT_DEVICE_EVENTevent.EV_EFI_ACTION"Calling EFI Application from Boot Option" if there is a
EV_OMIT_BOOT_DEVICE_EVENTevent. We already don't enforce theexistence of the
EV_EFI_ACTIONevent if there is noEV_OMIT_BOOT_DEVICE_EVENTevent even though it should be there,because we know that some firmware misbehaves here.
SysPrepOrderandSysPrep variables on the
BootOptionSupportflags.Fixes: #517
Fixes: #519