u-boot.git/lib, branch v2024.01-rc4 Unnamed repository; edit this file 'description' to name the repository. efi_loader: generated SMBIOS table below 4 GiB 2023-12-04T18:42:40+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2023-11-20T22:25:58+00:00 89cb3a9f0a5583d6a2197de64a22ef1e4d2e220b We currently use an outdated format 32-bit format for SMBIOS tables. So we must allocate SMBIOS tables below 4 GiB. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> 
We currently use an outdated format 32-bit format for SMBIOS tables.
So we must allocate SMBIOS tables below 4 GiB.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: improve efi_var_from_file() description 2023-11-20T18:06:22+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2023-11-13T14:50:16+00:00 ce68a254483817f86f92ffef7c7bc44fee318fb5 It is unclear to developers why efi_var_from_file() returns EFI_SUCCESS if file ubootefi.var is missing or corrupted. Improve the description. Reported-by: Weizhao Ouyang <o451686892@gmail.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Weizhao Ouyang <o451686892@gmail.com> 
It is unclear to developers why efi_var_from_file() returns EFI_SUCCESS if
file ubootefi.var is missing or corrupted. Improve the description.

Reported-by: Weizhao Ouyang <o451686892@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>
efi_loader: Correctly account the SCRTM event creation 2023-11-20T18:06:22+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2023-11-07T11:31:34+00:00 229f9e77fe46efb2516b7cfdc60db1d92721eac5 The result of efi_append_scrtm_version() is overwritten before anyone checks its result. Check it and exit the function on failures Addresses-Coverity-ID: 467399 Code maintainability issues (UNUSED_VALUE) Fixes: commit 97707f12fdab ("tpm: Support boot measurements") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
The result of efi_append_scrtm_version() is overwritten before anyone
checks its result. Check it and exit the function on failures

Addresses-Coverity-ID: 467399 Code maintainability issues (UNUSED_VALUE)
Fixes: commit 97707f12fdab ("tpm: Support boot measurements")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: Increase default variable store size to 128K 2023-11-20T18:06:22+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2023-11-06T15:47:53+00:00 a8062549d6ba81e41596adab83f80e8f819f491d In commit 9fd3f881c6ed ("efi_loader: Increase default variable store size to 64KiB") Alper has a detailed explanation of why the size needs to be bumped to at least 64K. However enabling Secure boot, writing db, KEK, PK etc keys will further increase the size so bump it to 128K. It's worth noting that when U-Boot stores the EFI variables in an RPMB the available storage is defined statically in StandAloneMM at build time. The U-Boot code is detecting the available true size on the fly during writes. When StandAloneMM is present this size defines the reserved memory U-Boot can use to copy any runtime variables, before booting an OS. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
In commit 9fd3f881c6ed ("efi_loader: Increase default variable store size to 64KiB")
Alper has a detailed explanation of why the size needs to be bumped to at
least 64K.  However enabling Secure boot, writing db, KEK, PK etc keys
will further increase the size so bump it to 128K.

It's worth noting that when U-Boot stores the EFI variables in an RPMB the
available storage is defined statically in StandAloneMM at build time.
The U-Boot code is detecting the available true size on the fly during
writes. When StandAloneMM is present this size defines the reserved
memory U-Boot can use to copy any runtime variables, before booting an
OS.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi: Correct handling of frame buffer 2023-11-15T03:04:00+00:00 Simon Glass sjg@chromium.org 2023-10-02T01:14:36+00:00 a75cf70d23ac8d4dbccf13f0a9589aaf6a552bff The efi_gop driver uses private fields from the video uclass to obtain a pointer to the frame buffer. Use the platform data instead. Check the VIDEO_COPY setting to determine which frame buffer to use. Once the next stage is running (and making use of U-Boot's EFI boot services) U-Boot does not handle copying from priv->fb to the hardware framebuffer, so we must allow EFI to write directly to the hardware framebuffer. We could provide a function to read this, but it seems better to just document how it works. The original change ignored an explicit comment in the video.h file ("Things that are private to the uclass: don't use these in the driver") which is why this was missed when the VIDEO_COPY feature was added. Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp") Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
The efi_gop driver uses private fields from the video uclass to obtain a
pointer to the frame buffer. Use the platform data instead.

Check the VIDEO_COPY setting to determine which frame buffer to use. Once
the next stage is running (and making use of U-Boot's EFI boot services)
U-Boot does not handle copying from priv->fb to the hardware framebuffer,
so we must allow EFI to write directly to the hardware framebuffer.

We could provide a function to read this, but it seems better to just
document how it works. The original change ignored an explicit comment
in the video.h file ("Things that are private to the uclass: don't use
these in the driver") which is why this was missed when the VIDEO_COPY
feature was added.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
fastboot: fix CRC32 chunk size checking 2023-10-31T13:36:30+00:00 Wojciech Nizinski niziak@spox.org 2023-09-25T10:37:15+00:00 355aab94d1f675ec1118906e1f88dfdf6a3582eb genimage create android-sparse file with CRC32 chunk at end. When U-Boot's fastboot receives this chunk it returns error message: `Fail Bogus chunk size for chunk type Dont Care` According to reference implementation of Android's sparse file format: <https://android.googlesource.com/platform/system/core/+/refs/heads/main/ libsparse/output_file.cpp#513> the chunk_header.total_sz is CHUNK_HEADER_LEN + 4 (CRC32 size). Signed-off-by: Wojciech Nizinski <niziak@spox.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3 Link: https://lore.kernel.org/r/20230925103714.4153612-1-niziak@spox.org Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> 
genimage create android-sparse file with CRC32 chunk at end. When
U-Boot's fastboot receives this chunk it returns error message:
`Fail Bogus chunk size for chunk type Dont Care`

According to reference implementation of Android's sparse file format:

<https://android.googlesource.com/platform/system/core/+/refs/heads/main/
libsparse/output_file.cpp#513>

the chunk_header.total_sz is CHUNK_HEADER_LEN + 4 (CRC32 size).

Signed-off-by: Wojciech Nizinski <niziak@spox.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3
Link: https://lore.kernel.org/r/20230925103714.4153612-1-niziak@spox.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
addrmap: Fix off by one in addrmap_set_entry() 2023-10-30T19:32:49+00:00 Dan Carpenter dan.carpenter@linaro.org 2023-07-25T06:50:40+00:00 7dd06b1621579262e5be46d78ba1d63c8afe8040 The > comparison needs to be changed to >= to prevent an out of bounds write on th next line. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
The > comparison needs to be changed to >= to prevent an out of bounds
write on th next line.

Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm 2023-10-27T23:27:29+00:00 Tom Rini trini@konsulko.com 2023-10-27T23:27:29+00:00 d5d9770f58ce0ba620e4d311bbd756b97839480a 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. 
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.
efi_loader: fix EFI_ENTRY point on get_active_pcr_banks 2023-10-27T20:01:47+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2023-10-19T16:21:55+00:00 946b311e47da22e409f2b0af5a3930db465e7eb8 efi_tcg2_get_active_pcr_banks doesn't immediately call the EFI_ENTRY() wrapper once it enters the function. Move the call a few lines above to cover the error cases properly as well. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
efi_tcg2_get_active_pcr_banks doesn't immediately call the
EFI_ENTRY() wrapper once it enters the function. Move the call a
few lines above to cover the error cases properly as well.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: fix EFI_ENTRY point on get_active_pcr_banks 2023-10-27T10:17:21+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2023-10-24T15:43:53+00:00 e9fc018a558ea931e599453e925d6cb5690112cb efi_tcg2_get_active_pcr_banks doesn't immediately call the EFI_ENTRY() wrapper once it enters the function. Move the call a few lines above to cover the error cases properly as well. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> 
efi_tcg2_get_active_pcr_banks doesn't immediately call the
EFI_ENTRY() wrapper once it enters the function. Move the call a
few lines above to cover the error cases properly as well.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>