Hi Ana On Fri, 30 Oct 2026 at 09:54, Ana Bobillo <[email protected]> wrote: > > 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.
This looks completely AI generated and unreviewed. What kind of Image are you expecting to boot and measure via EFI if it's not one of the defined types (10,11,12)? If you are worried about such an image shoudn't we check that in loadimage or startimage? The UEFI spec itself only lists these [0] > 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. > [0] https://uefi.org/specs/UEFI/2.11/02_Overview.html#uefi-images P.S: Again this is AI generated an I am personally ok to review them if they fix problems. Please do not copy paste what your LLM thought without reading it. Thanks /Ilias > Thanks, > Ana
