From 06eb1aa62ee926024663a424310ada02cf1c7a46 Mon Sep 17 00:00:00 2001 From: Mattijs Korpershoek Date: Tue, 4 Jun 2024 17:15:21 +0200 Subject: [PATCH 1/7] bootstd: Fix a handful of doc typos in bootmeth Fix some trivial typos found by browsing the code. Done with flyspell. Reviewed-by: Quentin Schulz Signed-off-by: Mattijs Korpershoek Reviewed-by: Guillaume La Roque Reviewed-by: Julien Masson --- include/bootmeth.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/bootmeth.h b/include/bootmeth.h index 0fc36104ece..9f94f8c06c8 100644 --- a/include/bootmeth.h +++ b/include/bootmeth.h @@ -40,7 +40,7 @@ struct bootmeth_ops { /** * get_state_desc() - get detailed state information * - * Prodecues a textual description of the state of the bootmeth. This + * Produces a textual description of the state of the boot method. This * can include newline characters if it extends to multiple lines. It * must be a nul-terminated string. * @@ -138,7 +138,7 @@ struct bootmeth_ops { * @dev: Bootmethod device to boot * @bflow: Bootflow to boot * Return: does not return on success, since it should boot the - * Operating Systemn. Returns -EFAULT if that fails, -ENOTSUPP if + * operating system. Returns -EFAULT if that fails, -ENOTSUPP if * trying method resulted in finding out that is not actually * supported for this boot and should not be tried again unless * something changes, other -ve on other error @@ -151,7 +151,7 @@ struct bootmeth_ops { /** * bootmeth_get_state_desc() - get detailed state information * - * Prodecues a textual description of the state of the bootmeth. This + * Produces a textual description of the state of the boot method. This * can include newline characters if it extends to multiple lines. It * must be a nul-terminated string. * @@ -244,7 +244,7 @@ int bootmeth_read_file(struct udevice *dev, struct bootflow *bflow, * @dev: Bootmethod device to use * @bflow: Bootflow to read * Return: does not return on success, since it should boot the - * Operating Systemn. Returns -EFAULT if that fails, other -ve on + * operating system. Returns -EFAULT if that fails, other -ve on * other error */ int bootmeth_read_all(struct udevice *dev, struct bootflow *bflow); @@ -255,7 +255,7 @@ int bootmeth_read_all(struct udevice *dev, struct bootflow *bflow); * @dev: Bootmethod device to boot * @bflow: Bootflow to boot * Return: does not return on success, since it should boot the - * Operating Systemn. Returns -EFAULT if that fails, other -ve on + * operating system. Returns -EFAULT if that fails, other -ve on * other error */ int bootmeth_boot(struct udevice *dev, struct bootflow *bflow); @@ -264,7 +264,7 @@ int bootmeth_boot(struct udevice *dev, struct bootflow *bflow); * bootmeth_setup_iter_order() - Set up the ordering of bootmeths to scan * * This sets up the ordering information in @iter, based on the selected - * ordering of the bootmethds in bootstd_priv->bootmeth_order. If there is no + * ordering of the boot methods in bootstd_priv->bootmeth_order. If there is no * ordering there, then all bootmethods are added * * @iter: Iterator to update with the order From 88b2eb0c393c3b83926bdce0ff1ee893445064e6 Mon Sep 17 00:00:00 2001 From: Daniel Schultz Date: Wed, 12 Jun 2024 09:16:37 -0700 Subject: [PATCH 2/7] doc: board: phytec: phycore-am62x: Fix Link to Documentation We moved our documentation to another hoster and therefore the URL changed. Point to the latest documentation instead of release versions to not link out-dated documentation. Signed-off-by: Daniel Schultz Reviewed-by: Wadim Egorov --- doc/board/phytec/phycore-am62x.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst index bc6d5246694..681ac536125 100644 --- a/doc/board/phytec/phycore-am62x.rst +++ b/doc/board/phytec/phycore-am62x.rst @@ -155,4 +155,4 @@ Further Information ------------------- Please see :doc:`../ti/am62x_sk` chapter for further AM62 SoC related documentation -and https://docs.phytec.com/phycore-am62x for vendor documentation. +and https://docs.phytec.com/projects/yocto-phycore-am62x/en/latest/ for vendor documentation. From 48752c599401f46fe7657a21849b0a5bbd22f816 Mon Sep 17 00:00:00 2001 From: Daniel Schultz Date: Wed, 12 Jun 2024 09:16:38 -0700 Subject: [PATCH 3/7] doc: board: phytec: phycore-am64x: Fix Link to Documentation We moved our documentation to another hoster and therefore the URL changed. Point to the latest documentation instead of release versions to not link out-dated documentation. Signed-off-by: Daniel Schultz --- doc/board/phytec/phycore-am64x.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/phytec/phycore-am64x.rst b/doc/board/phytec/phycore-am64x.rst index a27ad01027b..c99d8f6dd58 100644 --- a/doc/board/phytec/phycore-am64x.rst +++ b/doc/board/phytec/phycore-am64x.rst @@ -156,4 +156,4 @@ Further Information ------------------- Please see :doc:`../ti/am64x_evm` chapter for further AM64 SoC related documentation -and https://docs.phytec.com/phycore-am64x for vendor documentation. +and https://docs.phytec.com/projects/yocto-phycore-am64x/en/latest/ for vendor documentation. From 38720c8f9408aead6c9907d3f250020d4db1685f Mon Sep 17 00:00:00 2001 From: Daniel Schultz Date: Wed, 12 Jun 2024 09:16:39 -0700 Subject: [PATCH 4/7] doc: board: phytec: phycore-am64: Fix phyBOARD Name The Carrier-Board for the pyhCORE-AM64x is called phyBOARD-Electra. Signed-off-by: Daniel Schultz --- doc/board/phytec/phycore-am64x.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/phytec/phycore-am64x.rst b/doc/board/phytec/phycore-am64x.rst index c99d8f6dd58..ad9f47d9dfd 100644 --- a/doc/board/phytec/phycore-am64x.rst +++ b/doc/board/phytec/phycore-am64x.rst @@ -9,7 +9,7 @@ SoM (System on Module) featuring TI's AM64x SoC. It can be used in combination with different carrier boards. This module can come with different sizes and models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM64x family. -A development Kit, called `phyBOARD-Lyra `_ +A development Kit, called `phyBOARD-Electra `_ is used as a carrier board reference design around the AM64x SoM. Quickstart From d69759aec28ec195bc20e31b5558f99a32e3ab28 Mon Sep 17 00:00:00 2001 From: Ilias Apalodimas Date: Fri, 14 Jun 2024 15:09:50 +0300 Subject: [PATCH 5/7] tpm: measure DTB in PCR1 instead of PCR0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The PC client spec [0], doesn't describe measurements for DTBs. It does describe what do to for ACPI tables though. 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. The general description also mentions PCR0 is for code and PCR1 is for data such as ACPI and SMBIOS. So let's switch over the DTB measurements to PCR1 which seems a better fit. [0] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification Reported-by: Heinrich Schuchardt Signed-off-by: Ilias Apalodimas Reviewed-by: Eddie James --- boot/bootm.c | 2 +- lib/efi_loader/efi_tcg2.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/boot/bootm.c b/boot/bootm.c index 032f5a4a160..9879e1bba4e 100644 --- a/boot/bootm.c +++ b/boot/bootm.c @@ -964,7 +964,7 @@ int bootm_measure(struct bootm_headers *images) goto unmap_initrd; if (IS_ENABLED(CONFIG_MEASURE_DEVICETREE)) { - ret = tcg2_measure_data(dev, &elog, 0, images->ft_len, + ret = tcg2_measure_data(dev, &elog, 1, images->ft_len, (u8 *)images->ft_addr, EV_TABLE_OF_DEVICES, strlen("dts") + 1, diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index 945aafb847d..d56bd5657c8 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -1331,7 +1331,7 @@ efi_status_t efi_tcg2_measure_dtb(void *dtb) sha256_update(&hash_ctx, (u8 *)dtb + fdt_off_mem_rsvmap(dtb), rsvmap_size); sha256_finish(&hash_ctx, blob->data + blob->blob_description_size); - ret = measure_event(dev, 0, EV_POST_CODE, event_size, (u8 *)blob); + ret = measure_event(dev, 1, EV_POST_CODE, event_size, (u8 *)blob); free(blob); return ret; From 00cac7456125a2ab76ea30d32d78f4a2b177b2b3 Mon Sep 17 00:00:00 2001 From: Ilias Apalodimas Date: Fri, 14 Jun 2024 15:14:03 +0300 Subject: [PATCH 6/7] doc: describe UEFI measured boot 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 Reviewed-by: Heinrich Schuchardt --- doc/usage/measured_boot.rst | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst index 9691904a9d8..05c439e9ac6 100644 --- a/doc/usage/measured_boot.rst +++ b/doc/usage/measured_boot.rst @@ -7,19 +7,46 @@ 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 measured boot +------------------ + +The EFI subsystem implements the `EFI TCG protocol +`_ +and the `TCG PC Client Specific Platform Firmware Profile Specification +`_ +which defines the binaries to be measured and the corresponding PCRs to be used. + +Requirements +~~~~~~~~~~~~ + +* A hardware TPM 2.0 supported 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 1 + +Legacy measured boot +-------------------- + +The commands booti, bootm, and bootz can be used for measured boot +using the legacy entry point of the Linux kernel. + 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. +CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image in PCR1. 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 ------------- +~~~~~~~~~~~~ -* A hardware TPM 2.0 supported by the U-Boot drivers -* CONFIG_TPM=y +* A hardware TPM 2.0 supported by an enabled U-Boot driver +* CONFIG_TPMv2=y * CONFIG_MEASURED_BOOT=y * Device-tree configuration of the TPM device to specify the memory area for event logging. The TPM device node must either contain a phandle to From d1499a8b3fa30e4d835a139e958fc7bec96af412 Mon Sep 17 00:00:00 2001 From: Alexander Dahl Date: Tue, 11 Jun 2024 16:40:31 +0200 Subject: [PATCH 7/7] doc: Fix link reference to general verified boot docs Fixes: ad29e08b79fd ("doc: Bring in FIT signature files") Signed-off-by: Alexander Dahl Reviewed-by: Simon Glass --- doc/usage/fit/signature.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index 03a71b5192d..b868dcbf9fd 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -15,7 +15,7 @@ that it can be verified using a public key later. Provided that the private key is kept secret and the public key is stored in a non-volatile place, any image can be verified in this way. -See verified-boot.txt for more general information on verified boot. +See :doc:`verified-boot` for more general information on verified boot. Concepts