Hi Ilias, On Fri, 30 Oct 2026 at 09:22, Ilias Apalodimas wrote: > This is a policy decision. The logic behind this is that the OS is > responsible for catching wrong measurements, not the firmware. > E.g sealed keys etc would fail. If someone cares so much about > security, wouldn't EFI secure boot be enough to verify the image? IOW > do have use cases where people rely *only* on a TPM for security?
The OS can catch a wrong measurement, but not a missing one. An image that U-Boot starts without measuring it runs with boot services, so it can load and start the expected boot loader itself. That loader is measured as usual, and PCR 4 and the event log come out as for a good boot: keys sealed to them unseal, and attestation passes. No broken image is needed for that. An application whose Subsystem field holds a value U-Boot does not know, say 3, is loaded all the same (efi_set_code_and_data_type() logs "invalid image type" and gives it an application's memory types), tcg2_measure_pe_image() returns EFI_UNSUPPORTED before hashing it, and efi_load_pe() goes on. On sandbox, LoadImage() of such an image returns EFI_SUCCESS and leaves PCR 4 as it was, while the same image with subsystem 10 extends it. efi_start_image() then skips efi_tcg2_measure_efi_app_invocation() as well, since its image_type is not IMAGE_SUBSYSTEM_EFI_APPLICATION, so the "Calling EFI Application from Boot Option" event and the separators are measured only once it starts the real loader, as when U-Boot starts that loader directly. With Secure Boot on, the patch changes nothing in practice: such an image fails efi_image_authenticate(), since the Subsystem field is covered by the signature and an image efi_image_parse() rejects fails it too, so it is never started. It matters with measured boot and no Secure Boot, which is common on boards where nobody provisions Secure Boot keys: disk keys sealed to PCRs (systemd-cryptenroll --tpm2-pcrs, Clevis) and remote attestation (Keylime) rely on the measurements, not on Secure Boot. There an attacker who can write to the ESP can run what they like, but it is measured and the seal breaks; an image that escapes the measurement leaves the seal intact. > Doesn't EDKII also disable the TPM if Tcg2HashLogExtendEvent fails? So > does it allow to load further images without measuring if the > measurements fail? Only when the TPM itself fails. Tcg2HashLogExtendEvent() in Tcg2Dxe clears TPMPresentFlag when MeasurePeImageAndExtend() returns EFI_DEVICE_ERROR, and reports a TPM interface error. Even then the image being measured is not loaded: DxeTpm2MeasureBootHandler() returns the error, and CoreLoadImage() fails on any error of a security handler but EFI_SECURITY_VIOLATION. Later images do load unmeasured, as on a platform without a TPM, but nothing is extended any more, so the PCRs stop short of a good boot's values and sealed keys fail. That is the case the OS catches. An image EDK2 cannot measure because of what it is, one that PeCoffLoaderGetImageInfo() rejects or whose subsystem Tcg2MeasurePeImage() does not know, gets an error that leaves the TPM on, and is refused the same way. So EDK2 does not start an image it failed to measure while later measurements still work, and that is what this patch stops U-Boot from doing. On a TPM error, the patch refuses the image as EDK2 does. In v2 I will name the subsystem case in the commit message and add it to the unit test, and carry your Reviewed-by on 01 and 03. Thanks, Ana
