The purpose of this error is to indicate the presence of third party code signed by a secure boot CA that's not explicitly trusted, in this case, the Microsoft UEFI CA. We already ignore EV_EFI_BOOT_SERVICES_DRIVER and EV_EFI_RUNTIME_SERVICES_DRIVER events from SPI flash, but some systems we tested in the cert lab are triggering this error with option ROMs that don't appear to have a corresponding EV_EFI_VARIABLE_AUTHORITY event in PCR7 and therefore weren't authenticated with secure boot. Whilst these systems might need further investigation, it's likely that these option ROMs were loaded from integrated PCI devices.
We should ignore EV_EFI_BOOT_SERVICES_DRIVER and EV_EFI_RUNTIME_SERVICES_DRIVER events for option ROMs from integrated PCI devices. This is slightly complex because we need to:
- Figure out how to map EFI device paths to something in sysfs.
- Understand if it's possible to determine if a PCI device is integrated.
The purpose of this error is to indicate the presence of third party code signed by a secure boot CA that's not explicitly trusted, in this case, the Microsoft UEFI CA. We already ignore
EV_EFI_BOOT_SERVICES_DRIVERandEV_EFI_RUNTIME_SERVICES_DRIVERevents from SPI flash, but some systems we tested in the cert lab are triggering this error with option ROMs that don't appear to have a correspondingEV_EFI_VARIABLE_AUTHORITYevent in PCR7 and therefore weren't authenticated with secure boot. Whilst these systems might need further investigation, it's likely that these option ROMs were loaded from integrated PCI devices.We should ignore
EV_EFI_BOOT_SERVICES_DRIVERandEV_EFI_RUNTIME_SERVICES_DRIVERevents for option ROMs from integrated PCI devices. This is slightly complex because we need to: