| Age | Commit message (Collapse) | Author |
|---|
|
The add_u_boot_and_runtime() function paints with a broad brush,
considering all of the memory from the top of U-Boot stack to
gd->ram_top as EFI_RUNTIME_SERVICES_CODE
This is fine, but we need to make sure we don't add a separate entry for
any ACPI tables in this region (which happens when bloblist is used for
tables). Otherwise the memory map looks strange and we get a test
failure on qemu-x86 (only) for the 'virtual address map' test.
Good map:
Type Start End Attributes
================ ================ ================ ==========
CONVENTIONAL 0000000000000000-00000000000a0000 WB
RESERVED 00000000000a0000-00000000000f0000 WB
RUNTIME DATA 00000000000f0000-00000000000f2000 WB|RT
RESERVED 00000000000f2000-0000000000100000 WB
CONVENTIONAL 0000000000100000-0000000005cc7000 WB
BOOT DATA 0000000005cc7000-0000000005ccc000 WB
RUNTIME DATA 0000000005ccc000-0000000005ccd000 WB|RT
BOOT DATA 0000000005ccd000-0000000005cce000 WB
RUNTIME DATA 0000000005cce000-0000000005cf0000 WB|RT
BOOT DATA 0000000005cf0000-0000000006cf5000 WB
RESERVED 0000000006cf5000-0000000006cfa000 WB
ACPI RECLAIM MEM 0000000006cfa000-0000000006d1c000 WB
RESERVED 0000000006d1c000-0000000006f35000 WB
RUNTIME CODE 0000000006f35000-0000000006f37000 WB|RT
RESERVED 0000000006f37000-0000000008000000 WB
RESERVED 00000000e0000000-00000000f0000000 WB
Bad map: (with BLOBLIST_TABLES but without this patch):
Type Start End Attributes
================ ================ ================ ==========
CONVENTIONAL 0000000000000000-00000000000a0000 WB
RESERVED 00000000000a0000-00000000000f0000 WB
ACPI RECLAIM MEM 00000000000f0000-00000000000f1000 WB
RESERVED 00000000000f1000-0000000000100000 WB
CONVENTIONAL 0000000000100000-0000000005ca5000 WB
BOOT DATA 0000000005ca5000-0000000005caa000 WB
RUNTIME DATA 0000000005caa000-0000000005cab000 WB|RT
BOOT DATA 0000000005cab000-0000000005cac000 WB
RUNTIME DATA 0000000005cac000-0000000005cce000 WB|RT
BOOT DATA 0000000005cce000-0000000006cd3000 WB
RUNTIME DATA 0000000006cd3000-0000000006cd5000 WB|RT
BOOT DATA 0000000006cd5000-0000000006cf4000 WB
RESERVED 0000000006cf4000-0000000006cf9000 WB
ACPI RECLAIM MEM 0000000006cf9000-0000000006ce6000 WB
Signed-off-by: Simon Glass <[email protected]>
|
|
QEMU can have its own internal ACPI and SMBIOS tables. At present U-Boot
copies out the SMBIOS tables but points directly to the ACPI ones.
The ACPI tables are not aligned on a 4KB boundary, which means that UPL
cannot use them directly, since it uses a reserved-memory node for the
tables and that it assumed (by EDK2) to be 4KB-aligned.
On x86, QEMU provides the tables in a mapped memory region and U-Boot
makes use of these directly, thus making it difficult to use any common
code.
Adjust the logic to fit within the existing table-generation code. Use a
bloblist always and ensure that the ACPI tables is placed in an aligned
region. Set a size of 8K for QEMU. This does not actually put all the
tables in one place, for QEMU, since it currently adds a pointer to the
tables in QFW.
On ARM, enable bloblist so that SMBIOS tables can be added to the
bloblist.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add a new initialiser which can accept a constant pointer.
Signed-off-by: Simon Glass <[email protected]>
|
|
In many cases it is useful to get the address of a buffer, e.g. when
booting from it. Add a function to handle this.
Signed-off-by: Simon Glass <[email protected]>
|
|
When using the ACPI tables supplied by QEMU, we don't need to build the
FADT and MADT tables in U-Boot.
This patch avoids a build failure
make qemu-riscv64_smode_defconfig acpi.config
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_fadt':
lib/acpi/acpi_table.c:265:(.text.acpi_write_fadt+0x15c):
undefined reference to `acpi_fill_fadt'
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_madt':
lib/acpi/acpi_table.c:294:(.text.acpi_write_madt+0x52):
undefined reference to `acpi_fill_madt'
Fixes: f5f7962091e4 ("acpi: x86: Write FADT in common code")
Fixes: 4a3fc0f525da ("acpi: x86: Move MADT to common code")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Patrick Rudolph <[email protected]>
|
|
In reworking the BLK usage in Kconfig, I found there's a few issues with
EFI_LOADER=y and BLK=n. In general, we can easily say that
lib/efi_loader/efi_file.c also should only be built with CONFIG_BLK.
That however leaves the bootmgr code, eficonfig code and then parts of
efi_device_path.c, efi_boottime.c and efi_setup.c which functionally
depend on BLK. While these calls can be if'd out, I'm unsure if the
result is usable. So rather than leave that buildable and imply that it
is, I'm leaving that combination non-buildable and commenting that
EFI_LOADER depends on BLK in the Kconfig currently.
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Philippe Reynes <[email protected]> says:
This serie adds the support of sha256_hmac and sha256_hkdf.
A first version was sent several months ago just before the
integration of mbedtls. This new version is based on mbedtls.
The first patch of this serie add the support of hkdf
using mbedtls.
Link: https://lore.kernel.org/r/[email protected]
|
|
Adds the support of key derivation using the scheme hkdf.
This scheme is defined in rfc5869.
Signed-off-by: Philippe Reynes <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
Adds the support of the hmac based on sha256.
This implementation is based on rfc2104.
Signed-off-by: Philippe Reynes <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
The function sha256_csum_wd is defined in lib/sha256.c
and in lib/mbedtls/sha256.c. To avoid duplicating this
function (and future function), we move this function
to the file lib/sha256_common.c
Reviewed-by: Raymond Mao <[email protected]>
Signed-off-by: Philippe Reynes <[email protected]>
|
|
Adds the support of key derivation using
the scheme hkdf.
Reviewed-by: Raymond Mao <[email protected]>
Signed-off-by: Philippe Reynes <[email protected]>
|
|
This function is not called from outside this file and has no entry in
the header file, so mark it static.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Move this code into a function so it can be called from elsewhere.
Note that the recently added network code uses the same
'global variable' approach. It could use a separate clean-up.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Except for the architecture specific lines ARM and RISC-V can use the same
linker script. Move the common lines to an include.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Raymond Mao <[email protected]> says:
Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
Object Handles in Type #2 and Contained Elements in Type #3)
Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
and values which cannot be retrieved from the system registers.
Vendors can create their own SMBIOS node using this as an example.
For those boards without SMBIOS nodes, this DTS file can be included to
have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
Type #4.
6. To minimize size-growth for those platforms which have not sufficient
ROM spaces or the platforms which don't need detailed SMBIOS
information, new added fields are only being built when kconfig
GENERATE_SMBIOS_TABLE_VERBOSE is selected.
Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).
Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
| dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
-dtb merged.dtb
```
Link: https://lore.kernel.org/r/[email protected]
|
|
Add detailed SMBIOS information as following:
1. Missing fields in Type #3 and #4
2. Type #7
Add support to dynamic length of contained object handles and
elements.
As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Current smbios library does not fully match to the specification.
It hardcodes values instead of exposing values from the device.
It does not reserve the space to support dynamic length for
contained object handles or elements and misses the handling of
a few of fields.
The refactoring of this patch includes:
1. Expose values from device via sysinfo interface.
2. Replace smbios_add_prop with smbios_add_prop_si to allow getting
string values from sysinfo.
3. Add smbios_get_val_si to get values from sysinfo or device tree.
4. Use sysinfo_get_data to get data area.
5. Reserve the space of contained object handles and elements.
6. Miscellaneous fixes in smbios.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Move the smbios field definitions to a separated simple headfile,
which is a prerequisite to be included by dts files.
Add new definitions for cache information.
This patch also includes a few of code optimizations in smbios.
Signed-off-by: Raymond Mao <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tpm
A few changes for the TPM subsystem wrt to EventLong creation and measurements.
Generally speaking it's insecure for a TPM to not cap all the active PCRs
when performing measurements.
Up to now we had code querying the active PCR banks on the fly and reason
whether it should perform a measurement or not. Since a TPM requires a reset
to change the active PCR banks, it's easier and faster to store them in an
array in the device private data and check against that.
This relates to an interesting feature some bootloaders have. For example
TF-A can't extend a PCR since it has no TPM drivers, but can produce an
EventLog that U-Boot can replay on the hardware once that comes up.
The supported hash algorithms of the TF-A generated Eventlog are generated
at compile time. When trying to replay an EventLog the TPM active PCR banks
and the created EventLog algorithms must agree. We used to report an error
but that changed in commit 97707f12fdab ("tpm: Support boot measurements").
This PR also brings up the old behavior and an error is reported now while
printing a human readable list of the mismatched algorithms.
|
|
To allow disabling algorithms for tcg2, in function
tcg2_create_digest(), each hash algorithm operations should under
the hash kconfig control to avoid building errors when the algorithm
is disabled.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We used to stop replaying an EventLog if parsing failed, but that got
lost in commit 97707f12fdab ("tpm: Support boot measurements").
When an EventLog is passed yo us from a previous bootloader, we want to
validate it as much as we can and make sure the defined PCR banks of
the log exist in our TPM and firmware so we can replay it if needed or
use it as-in, in case the PCRs are already extended.
So let's add the checks back and while at it simplify the logic of
rejecting an EventLog.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
A previous patch is storing the active PCR banks on the TPM private
data. Instead of parsing them on the fly use the stored values.
This allows us to simplify our checks during the log creation and
parsing.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
A previous patch is storing the active PCR banks on the TPM private
data. Instead of parsing them on the fly use the stored values.
This allows us to simplify our checks during the log creation and
parsing.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We have a lot of code trying to reason about the active TPM PCRs
when creating an EventLog. Since changing the active banks can't
be done on the fly and requires a TPM reset, let's store them
in the chip private data instead.
Upcoming patches will use this during the EventLog creation.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We already check the active banks vs what U-Boot was compiled with when
trying to extend a PCR and we refuse to do so if the TPM active ones
don't match the ones U-Boot supports.
Do the same thing for the EventLog creation since extending will fail
anyway and print a message so the user can figure out the missing
algorithms.
Co-developed-by: Raymond Mao <[email protected]>
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Add a bool var into hash_algo_list to indicate whether the algorithm
is supported or not and move the IS_ENABLED to only cover this var.
So that we can have the name, hash, mask and size no matter the
digest kconfigs are enabled or not.
In before, tpm2_algorithm_to_len() and tcg2_algorithm_to_mask() are used to
identify an unsupported algorithm when they return 0.
It is not the case now when hash_algo_list always provides algorithm size
and mask, thus a new API is introduced to check if an algorithm is
supported by U-Boot.
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Rename the arguments of tcg2_get_pcr_info() to clarify
they are bank masks, not PCR mask.
Remove the unused local variable.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When that function was introduced we were only using it to check if
extending a PCR was allowed, so the name made sense. A few patches ago
we used that function to reason about the EventLog creation and general
usage of PCRs , so let's rename it to something more generic that makes
more sense in all contexts.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
This function is checking for active PCR banks, so rename it
to something that's easier to read and closer to what the function
does.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
This is done so that the device path protocol interface of the network
device can be changed internally by u-boot when a new bootfile gets
downloaded.
Signed-off-by: Adriano Cordova <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Check for an error returned from the decompress() function, just in
case.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The fix provided by 997fc12ec91 is actually introducing
a buffer overrun, and the overrun is effective if the
memory after the reloc section is not zeroed.
Probably that's why this bug is not always noticeable.
The problem is that 8-bytes 'rel' pointer can be 4-bytes aligned
according to the PE Format, so the actual relocate function can
take values after the reloc section.
One example is the following dump from the reloc section:
bce26000: 3000 0000 000c 0000 0000 0000 0000 0000
bce26010: 7c00 9340 67e0 f900 1c00 0ea1 a400 0f20
This section has two relocations at offset bce26008 and bce2600a,
however the given size (rel_size) for this relocation is 16-bytes
and this is coming form the efi image Misc.VirtualSize, so in this
case the 'reloc' pointer ends at affset bce2600c and is taken as
valid and this is where the overflow is.
In our system we see this problem when we are starting the
Boot Guard efi image.
This patch is fixing the overrun while preserving the fix done
by 997fc12ec91.
Signed-off-by: Aleksandar Gerasimovski <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When the TCG2 protocol installation fails, we are trying to remove
all the objects we created in tcg2_uninit().
However, there are cases when this function runs before the config
table was installed. So instead of printing an error unconditionally
check against EFI_NOT_FOUND and don't print anything if the table wasn't
installed to begin with.
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We should not write messages in UEFI API functions. This may lead to
incorrect screen layout in UEFI application.
For single statements after if clause we don't need braces.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Jerome Forissier <[email protected]> says:
This short series adds the 'trace wipe' command which clears the trace
buffer, allowing to re-start a capture from scratch.
Link: https://lore.kernel.org/r/[email protected]
|
|
Implement a 'trace wipe' command to delete the currently accumulated
trace data. This comes handy when someone needs to trace a particular
command. For example:
=> trace pause; trace wipe
=> trace resume; dhcp; trace pause
=> trace stats
=> trace calls 0x02100000 0x10000000
=> tftpput $profbase $profoffset 192.168.0.16:trace.bin
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Evgeny Bachinin <[email protected]> says:
The 1st patch addresses comments from the post-review, available by
link [1].
The 2nd patch fixes problems of dtb_dt_embedded() with checkpatch.
Links:
[1] https://lore.kernel.org/u-boot/CAFLszTgEKamsa6FTnjzrEWQBLkqAR7EBbZqffx09AKgQ7ppuVA@mail.gmail.com/#t
Link: https://lore.kernel.org/r/20241211-dtb_dt_embedded_within_fdtdec-v1-0-7840469f0084@salutedevices.com
|
|
Patch fixes the checkpatch warnings like:
```
WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
#94: FILE: lib/fdtdec.c:102:
+#ifdef CONFIG_OF_EMBED
```
Signed-off-by: Evgeny Bachinin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Patch keeps the access to dtb_dt_embedded() within fdtdec API,
by means of new API function introduction. This new function is a
common place for updating appropriate global_data fields for
OF_EMBED case.
Also, the consequence of the patch is movement of '___dtb_dt_*begin'
symbols' declaration from header file, because nobody used symbols
outside the lib/fdtdec.c.
Signed-off-by: Evgeny Bachinin <[email protected]>
Suggested-by: Simon Glass <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
lmb_alloc_addr_flags() is a wrapper for _lmb_alloc_addr() and it's the
only function using it. Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()
and remove the wrapper.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE.
There's not much we gain from this abstraction, so let's remove the
former add the flags argument to lmb_alloc_base() and make the code
a bit easier to follow.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE
There's not much we gain from this abstraction, so let's remove the
latter, add a flags argument to lmb_alloc_addr() and make the code a
bit easier to follow.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
There's no point defining a function that's called only once just to
avoid passing the flags. Remove the wrapper and just call
lmb_add_region_flags().
Acked-by: Sughosh Ganu <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
free_mem is a misnomer. We never update it with the free memory for
LMB. Instead, it describes all available memory and is checked against
used_mem to decide whether an area is free or not.
So let's rename this field to better match its usage.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
LMB flags is not an enum anymore. It's currently used as a bitmask
in various places of our code. So make it a u32 which is more
appropriate when dealing with masks.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We already have a macro for this. Use it instead of adding yet another
variant for alignment.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Fix warnings from kernel-doc script. Improve and unify overall style of
kernel-doc comments in lmb source files. Move all kernel-doc comments
for public functions into the header, as recommended in U-Boot
documentation [1]:
Non-trivial functions should have a comment which describes what
they do. If it is an exported function, put the comment in the
header file so the API is in one place. If it is a static function,
put it in the C file.
This also takes care of existing duplication. While at it, do a bit of
cosmetic cleanups as well.
No functional change.
[1] doc/develop/codingstyle.rst
Signed-off-by: Sam Protsenko <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Fix checkpatch warnings. No functional change.
Signed-off-by: Sam Protsenko <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
flag_str[] is a pointer to const. Make it also a const pointer. Improve
a style a bit while a it, to make this line fit 80 characters limit.
No functional change.
Signed-off-by: Sam Protsenko <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
