[PATCH] doc: describe UEFI measured boot

Heinrich Schuchardt xypron.glpk at gmx.de
Fri Jun 14 14:18:29 CEST 2024


On 14.06.24 12:47, Ilias Apalodimas wrote:
> [...]
>
>>
>>> +
>>> +UEFI requirements
>>> +~~~~~~~~~~~~~~~~~
>>> +* A hardware TPM 2.0 supported by the U-Boot drivers
>>
>> by an enabled U-Boot driver.
>>
>>> +* CONFIG_EFI_TCG2_PROTOCOL=y
>>> +* CONFIG_EFI_TCG2_PROTOCOL_EVENTLOG_SIZE=y
>>> +* optional CONFIG_EFI_TCG2_PROTOCOL_MEASURE_DTB=y will measure the loaded DTB in PCR 0
>>
>> Why does this setting not default to yes?
>>
>> Should EFI_TCG2_PROTOCOL_MEASURE_DTB depend on !GENERATE_ACPI_TABLE as
>> we won't load the device-tree in this case?
>>
>> I can't find any reference to device-trees in `TCG PC Client Platform
>> Firmware Profile Specification`.
>
> It's not and I've already pointed this out to Arm. We followed what
> ACPI does there and used "DTB DATA" instead of "ACPI DATA" as the
> event string.
>
>>   Where is PCR 0 for the device-tree specified?
>
> As I said DT is missing from the spec but look below
>
>> I read:
>>
>> "In general, the platform firmware measures into PCR[1] the
>> configuration data that is associated with the code that measured into
>> PCR[0]".
>>
>> This looks like PCR 1 should be the target for the device-tree.
>
> There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS,
> and Embedded Drivers and they explicitly mention ACPI in there.
> There's no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform
> Configuration.

3.3.4.1 "PCR[0] – SRTM, POST BIOS, and Embedded Driver" covers usage of
EV_POST_CODEs for different PCRs.

EV_POST_CODE is deprecated. That one could be used for ACPI_DATA.

EDK II:

SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c:660,
SecurityPkg/Tcg/TcgSmm/TcgSmm.c:379,
UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c:1226 measure with
deprecated EV_POST_CODE, EV_POSTCODE_INFO_ACPI_DATA to PCR[0]. This
seems to include a measurement of the ACPI TPM2 table.

OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c:426 measures with
EV_PLATFORM_CONFIG_FLAGS, EV_POSTCODE_INFO_ACPI_DATA to PCR[1].

MdeModulePkg/Universal/SmbiosMeasurementDxe/SmbiosMeasurementDxe.c:630
measures SMBIOS with EV_EFI_HANDOFF_TABLES to PCR[1].

>
> However ..... In Figure 6 PCR Mapping of UEFI Components ACPI is shown
> in PCR1 .....
> I am not sure if we should use PCR0 or 1, if anyone has a strong
> opinion we can easily change the measured PCR.

According to the cited sentence PCR 1 would make most sense.

>
>>
>> Do we already measure ACPI and SMBIOS tables into PCR1 as required by
>> the specification.
>
> We do measure SMBIOS in PCR1. I don't think we do anything for ACPI.

I guess the ACPI TPM2 table would be needed to access the TCG2 device
(see TCG ACPI Specification).

>
>>
>>> +
>>> +bootm
>>
>> Measured legacy boot with bootm command
>>
>> Please, consider in your description that the bootm command may be used
>> to load a FIT image with an EFI binary.
>
> I am not entirely sure how this works, someone who has used that needs
> to update it. What happens in that case? Does bootm end up calling
> bootefi ? That means we are measuring things twice?

We measure only once:

boot/bootm.c:925:

         /* Skip measurement if EFI is going to do it */
         if (images->os.os == IH_OS_EFI &&
             IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
             IS_ENABLED(CONFIG_BOOTM_EFI))
                 return ret;


do_bootm_efi() calls efi_binary_run().

Best regards

Heinrich

>
>>
>>> +-----
>>>    By default, U-Boot will measure the operating system (linux) image, the
>>>    initrd image, and the "bootargs" environment variable. By enabling
>>>    CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image.
>>> @@ -15,8 +35,8 @@ The operating system typically would verify that the hashes found in the
>>>    TPM PCRs match the contents of the event log. This can further be checked
>>>    against the hash results of previous boots.
>>>
>>> -Requirements
>>> -------------
>>> +bootm requirements
>>
>> This is already a sub-section of bootm. No need to repeat it.
>>
>>> +~~~~~~~~~~~~~~~~~~
>>>
>>>    * A hardware TPM 2.0 supported by the U-Boot drivers
>>
>> by an enabled U-Boot driver.
>>
>>>    * CONFIG_TPM=y
>>
>> CONFIG_TPM_V2=y is required?
>>
>> Best regards
>>
>> Heinrich
>>
>>
>
> Thanks
> /Ilias
>>



More information about the U-Boot mailing list