u-boot.git/boot/bootm.c, branch v2024.01

Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm

2023-10-27T23:27:29+00:00

bootX measurements and measurement API moved to u-boot core:

Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.

The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.

With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.

I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions.  Eddie tested the bootX part.

Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.

There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.

Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.

Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree.  The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless.  The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.

Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case.  I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.

bootm: Support boot measurement

2023-10-27T10:15:57+00:00

Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
Ilias: Added some info on Kconfig explaining this is when booting !EFI
Signed-off-by: Ilias Apalodimas

command: Include a required header in command.h

2023-10-06T18:38:13+00:00

This uses ARRAY_SIZE() but does not include the header file which declares
it. Fix this, so that command.h can be included without common.h

Signed-off-by: Simon Glass 
Reviewed-by: Mattijs Korpershoek

bootstd: cros: Add ARM support

2023-08-11T13:33:40+00:00

Support booting ChromiumOS on ARM devices using FIT. Add an entry into the
boot implementation which does not require a command line. This can be
expanded over time as the bootm code is refactored.

Signed-off-by: Simon Glass

bootm: don't call booti_setup for EFI images

2023-06-16T04:45:20+00:00

On the arm64 architecture booti_setup() is called for EFI FIT images.
This function call fails because EFI images typically do not have a
kernel signature.

Check that the operating system property "os" of the image is "linux"
before invoking booti_setup().

Fixes: 487b5fa6deb1 ("bootm: Handle kernel_noload on arm64")
Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass

android: boot: support boot image header version 3 and 4

2023-04-04T18:50:47+00:00

Enable the support for boot image header version 3 and 4
using abootimg command.

In order to use version 3 or 4:

1- Vendor boot image address should be given to abootimg cmd.

	abootimg addr $1 $vendor_boot_load_addr

2- "ramdisk_addr_r" env variable (ramdisk address) should be set to host
the ramdisk : generic ramdisk + vendor ramdisk

Replace "struct andr_boot_img_hdr_v0*" by "void *" in
some functions since v3 and v4 are now supported as well.

Signed-off-by: Safae Ouajih 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek

android: boot: add vendor boot image to prepare for v3, v4 support

2023-04-04T18:50:47+00:00

Introduce vendor boot image for version 3 and 4 of boot image header.
The vendor boot image will hold extra information about kernel, dtb
and ramdisk.

This is done to prepare for boot image version 3 and 4 support.

Signed-off-by: Safae Ouajih 
Reviewed-by: Simon Glass 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Mattijs Korpershoek

Correct SPL uses of CMD_FDT

2023-02-09T21:32:25+00:00

This converts 2 usages of this option to the non-SPL form, since there is
no SPL_CMD_FDT defined in Kconfig

Signed-off-by: Simon Glass

Correct SPL uses of CMD_BOOTM_PRE_LOAD

2023-02-09T21:32:25+00:00

This converts 2 usages of this option to the non-SPL form, since there is
no SPL_CMD_BOOTM_PRE_LOAD defined in Kconfig

Signed-off-by: Simon Glass

Correct SPL use of CMD_BOOTI

2023-02-09T21:32:25+00:00

This converts 1 usage of this option to the non-SPL form, since there is
no SPL_CMD_BOOTI defined in Kconfig

Signed-off-by: Simon Glass