| Message ID | 20240614094031.6013-1-ilias.apalodimas@linaro.org |
|---|---|
| State | Accepted |
| Commit | 00cac7456125a2ab76ea30d32d78f4a2b177b2b3 |
| Headers | show |
| Series | doc: describe UEFI measured boot | expand |
On 14.06.24 11:40, Ilias Apalodimas wrote: > We currently only describe the process to enable measured boot using > bootm. Describe the UEFI requirements as well which predate bootm. > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> > --- > doc/usage/measured_boot.rst | 24 ++++++++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst > index 9691904a9d8a..1b5dd1dcc438 100644 > --- a/doc/usage/measured_boot.rst > +++ b/doc/usage/measured_boot.rst > @@ -7,6 +7,26 @@ U-Boot can perform a measured boot, the process of hashing various components > of the boot process, extending the results in the TPM and logging the > component's measurement in memory for the operating system to consume. > > +The functionality is available when booting via the EFI subsystem or 'bootm' Thanks for adding a description for legacy measured boot. @Eddie Is it really only the bootm command? How about booti and bootz? Not measuring there would be quite inconsistent. Please, add a document link to doc/usage/cmd/bootm.rst. > +command. > + > +UEFI subsystem UEFI measured boot > +-------------- > +The EFI subsystem implements the `EFI TCG protocol > +<https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/>`_ > +and the `TCG PC Client Specific Platform Firmware Profile Specification > +<https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/>`_ > +which defines the binaries to be measured and the corresponding PCRs used. to be used. > + > +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`. Where is PCR 0 for the device-tree specified? 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. Do we already measure ACPI and SMBIOS tables into PCR1 as required by the 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. > +----- > 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
[...] > > > + > > +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. 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. > > 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. > > > + > > +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? > > > +----- > > 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 >
[...] > > > + > > +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? > Forgot to answer this. Measuring a DTB is far too circumstantial to be enabled by default. People inject all kind of stuff in there -- kaslr seeds and random mac addresses are just prime examples. To enable it by default, we need to do the measurements early and make sure the random artifacts aren't enabled by a previous stage bootloader. As a result we leave the decision to measure it per board. Regards /Ilias
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 >>
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst index 9691904a9d8a..1b5dd1dcc438 100644 --- a/doc/usage/measured_boot.rst +++ b/doc/usage/measured_boot.rst @@ -7,6 +7,26 @@ U-Boot can perform a measured boot, the process of hashing various components of the boot process, extending the results in the TPM and logging the component's measurement in memory for the operating system to consume. +The functionality is available when booting via the EFI subsystem or 'bootm' +command. + +UEFI subsystem +-------------- +The EFI subsystem implements the `EFI TCG protocol +<https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/>`_ +and the `TCG PC Client Specific Platform Firmware Profile Specification +<https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/>`_ +which defines the binaries to be measured and the corresponding PCRs used. + +UEFI requirements +~~~~~~~~~~~~~~~~~ +* A hardware TPM 2.0 supported by the U-Boot drivers +* 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 + +bootm +----- 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 +~~~~~~~~~~~~~~~~~~ * A hardware TPM 2.0 supported by the U-Boot drivers * CONFIG_TPM=y
We currently only describe the process to enable measured boot using bootm. Describe the UEFI requirements as well which predate bootm. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> --- doc/usage/measured_boot.rst | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)