You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have encountered a device that measures the EV_EFI_VARIABLE_AUTHORITY secure boot verification event for a UEFI driver that's not part of the platform firmware to PCR2. Whilst PCR2 is meant to be used to measure code that is executed outside of the platform firmware (eg, for PE images, measuring their Authenticode digest with the EV_EFI_BOOT_SERVICES_DRIVER or EV_EFI_RUNTIME_SERVICES_DRIVER event types), secure boot policy - which includes secure boot configuration (EV_EFI_VARIABLE_DRIVER_CONFIG event types) and secure boot verification events to indicate which CAs have been used to authenticate code (EV_EFI_VARIABLE_AUTHORITY event types) - should only be measured to PCR7.
In this case we have encountered, PCR7 is not useful on its own for determining secure boot policy - we will need a quirk to detect this case and make PCR2 a companion of PCR7 (ie, if PCR7 is included in the profile then PCR2 must also be included in order to seal keys against a device's secure boot policy).
Note that this will be working around a genuine firmware implementation bug.
The text was updated successfully, but these errors were encountered:
@kukrimate I can't assign you directly, but this should be a relatively easy bug to fix if you want to get involved and assign it to yourself (I can help to point out how I think things should change to accommodate this). Feel free to assign it to yourself if you want to.
We have encountered a device that measures the
EV_EFI_VARIABLE_AUTHORITY
secure boot verification event for a UEFI driver that's not part of the platform firmware to PCR2. Whilst PCR2 is meant to be used to measure code that is executed outside of the platform firmware (eg, for PE images, measuring their Authenticode digest with theEV_EFI_BOOT_SERVICES_DRIVER
orEV_EFI_RUNTIME_SERVICES_DRIVER
event types), secure boot policy - which includes secure boot configuration (EV_EFI_VARIABLE_DRIVER_CONFIG
event types) and secure boot verification events to indicate which CAs have been used to authenticate code (EV_EFI_VARIABLE_AUTHORITY
event types) - should only be measured to PCR7.In this case we have encountered, PCR7 is not useful on its own for determining secure boot policy - we will need a quirk to detect this case and make PCR2 a companion of PCR7 (ie, if PCR7 is included in the profile then PCR2 must also be included in order to seal keys against a device's secure boot policy).
Note that this will be working around a genuine firmware implementation bug.
The text was updated successfully, but these errors were encountered: