| Age | Commit message (Collapse) | Author |
|---|
|
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Introduce a new helper efi_capsule_update_info_gen_ids() which populates
the capsule update fw images image_type_id field. This allows for
determinstic UUIDs to be used that can scale to a large number of
different boards and board variants without the need to maintain a big
list.
We call this from efi_fill_image_desc_array() to populate the UUIDs
lazily on-demand.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
The EFI_LOADER and EFI config options are randomly scattered under lib/
making it cumbersome to navigate and enable options, unless you really
know what you are doing. On top of that the existing options are in
random order instead of a logical one.
So let's move things around a bit and move them under boot/. Present a
generic UEFI entry where people can select Capsules, Protocols,
Services, and an option to compile U-Boot as an EFI for X86
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
There's currently a chance for this function to overwrite an error if
one occurred and the subsequent call to
efi_uninstall_multiple_protocol_interfaces() succedded. Although this
is an EFI event and we can't do much let's at least set and return
the correct error
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
We use this event when returning from an EFI HTTP booted image.
The name is a bit confusing since it suggests we always run it,
rename it to make it clearer
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
We use this function to clean up leftover resources when booting an
EFI HTTP boot image, but the name is unnecessary long.
Shorten it to efi_bootmgr_release_uridp()
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Sughosh Ganu <[email protected]> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/[email protected]/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
|
|
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
|
|
There not only ARM64 boards but also RISC-V boards that require a bounce
buffer to read block devices.
Drop the architecture restriction.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
efi_get_var() allocates memory which must be freed after the variable is
used. Since the device path is duplicated after we deserialize the load
options free the memory used for the variable payload
Fixes: db61e70e0d2a efi_loader: efi_dp_from_lo() should skip VenMedia node
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinric Schuchardt <[email protected]>
|
|
Use the correct function name.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Simplify the code by using the list_count_nodes() function.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use the list_for_each_entry() API to get the efi_mem_list node
directly, instead of making an additional call to list_entry().
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Populate the previous memory descriptor node pointer only after it's
parent struct has been initialised. The compiler fixes this logic to
do the right thing, but it is better to have correct code in place.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Use the API function list_count_nodes() to count the number of EFI
memory map entries.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
After assigning to *dp we must check this value and not dp.
Addresses-Coverity-ID: 501792 Control flow issues (DEADCODE)
Fixes: 58bef195f94e ("cmd: eficonfig: add support for setting fdt")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Add an additional search path /dtbs, this is where dtbs are installed on
postmarketOS and potentially other distros.
Signed-off-by: Caleb Connolly <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
A system has to support booting via the boot manager to be EBBR compliant.
See the reference to variables Boot#### in the specification.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
EFI_IGNORE_OSINDICATIONS is used to ignore OsIndications if setvariable
at runtime is not supported and allow the platform to perform capsule
updates on disk. With the recent changes boards can conditionally enable
setvariable at runtime using EFI_RT_VOLATILE_STORE.
Let's make that visible in our Kconfigs and enable EFI_IGNORE_OSINDICATIONS
when set variable at runtime is disabled.
Since EFI_RT_VOLATILE_STORE needs help from the OS to persist the
variables, allow users to ignore OsIndications even if setvariable at
runtime is enabled.
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Fix typo in EFI_RT_VOLATILE_STORE description.
Fixes: c28d32f946f0 ("efi_loader: conditionally enable SetvariableRT")
Signed-off-by: Michal Simek <[email protected]>
|
|
The auto-generated load options for media device do not contain a partition
node. We cannot expect the simple file protocol here.
Get the partition device-path via the loaded image protocol.
Fixes: e91b68fd6b83 ("efi_loader: load distro dtb in bootmgr")
Reported-by: E Shattow <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Tested-by: E Shattow <[email protected]>
|
|
This removes a number of duplicate newlines throughout the codebase.
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
The dtbdump.efi binary can be used for testing the EFI_DT_FIXUP_PROTOCOL.
It provides a command to load a file and have it fixed up and a
command to save the resulting file.
Add a command 'dump' for displaying the device-tree.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
The EFI Capsule ESL file (EFI Signature List File) used for authentication
is a binary generated from the EFI Capsule public key certificate. Instead
of including it in the source repo, automatically generate it from the
certificate file during the build process.
Currently, sandbox is the only device using this, so removed its ESL file
and set the (new) CONFIG_EFI_CAPSULE_CRT_FILE config to point to its public
key certificate.
Signed-off-by: Jonathan Humphreys <[email protected]>
|
|
Tom Rini <[email protected]> says:
Prior to this series we had some de-facto required cache functions that
were either unimplemented on some architectures or differently named.
This would lead in some cases to having multiple "weak" functions
available as well. Rework things so that an architecture must provide
these functions and it is up to that architecture if a "weak" default
function makes sense, or not.
|
|
This function was used on measured boot to retrieve the number of active
PCR banks and was designed to work with the TCG protocols.
Since we now have the need to retrieve the active PCRs outside the
measured boot context -- e.g use the in the command line, decouple the
function.
Create one that will only adheres to TCG TSS2.0 [0] specification called
tpm2_get_pcr_info() which can be used by the TPM2.0 APIs and a new one that
is called from the measured boot context called tcg2_get_pcr_info()
[0] https://trustedcomputinggroup.org/wp-content/uploads/TSS_Overview_Common_Structures_Version-0.9_Revision-03_Review_030918.pdf
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
efi_tcg2.h already includes tpm-v2.h. Remove it
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Prepare v2024.07-rc5
|
|
A while back we moved the core functions of the EFI TCG protocol to the
TPM APIs in order for them to be used with bootm, booti etc.
Some prototypes changed from returning efi_status_t to int, which is more
appropriate for the non-EFI APIs. However, some of the EFI callsites never
changed and we ended up assigning the int value to efi_status_t.
This is unlikely to cause any problems, apart from returning invalid
values on failures and violating the EFI spec. Let's fix them
by looking at the new return code and map it to the proper EFI return
code on failures.
Fixes: commit 97707f12fdab ("tpm: Support boot measurements")
Fixes: commit d6b55a420cfc ("efi_loader: startup the tpm device when installing the protocol")
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
If multiple weak implementations of a weak function exist, it is unclear
which one the linker should chose. cmd/cache.c already defines a weak
invalidate_icache_all().
We don't need a call to invalidate_icache_all() on x86.
ARM, RISC-V, and Sandbox provide an implementation.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Eddie James <[email protected]>
|
|
Tom Rini <[email protected]> says:
Rework how the BLK symbol is used now that so much DM migration has been
completed.
|
|
The BLK symbol is used both for "we have a block device subsystem
enabled" and "we need to utilize the block device library functions". In
the case of efi_loader, it is the case of "we need to utilize the block
device library", so select rather than depends on it. In turn, also
disable EFI_LOADER on platforms which did not have it on previously due
to a lack of block devices. They can enable it themselves if desired.
Acked-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Comment is not kernel-doc format that's why don't label it like that and
also fix indentation to have proper multiline comment.
Signed-off-by: Michal Simek <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
According to UEFI v2.10 spec section 8.2.6, if a caller invokes the
SetVariables() service, it will produce a digest from hash(VariableName,
VendorGuid, Attributes, TimeStamp, DataNew_variable_content), then the
firmware that implements the SetVariable() service will compare the
digest with the result of applying the signer’s public key to the
signature. For EFI variable append write, efitools sign-efi-sig-list has
an option "-a" to add EFI_VARIABLE_APPEND_WRITE attr, and u-boot will
drop this attribute in efi_set_variable_int(). So if a caller uses
"sign-efi-sig-list -a" to create the authenticated variable, this append
write will fail in the u-boot due to "hash check failed".
This patch resumes writing the EFI_VARIABLE_APPEND_WRITE attr to ensure
that the hash check is correct. And also update the "test_efi_secboot"
test case to compliance with the change.
Signed-off-by: Weizhao Ouyang <[email protected]>
|
|
As we now also store device-tree device-paths in load options rename
struct efi_initrd_dp to efi_lo_dp_prefix.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
If no device-tree is specified, try to load a device-tree from the boot
device use the $fdtfile concatenated to either of the paths '/dtb/', '/',
'/dtb/current/'.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We can reuse this function to load the device-tree.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
For finding distro supplied device-trees we need to know from which device
we are booting. This can be identified via the device-path of the binary.
Up to now efi_dp_from_lo() only could return the initrd or fdt device-path.
Allow returning the binary device-path, too.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Move distro_efi_get_fdt_name() to a separate C module
and rename it to efi_get_distro_fdt_name().
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We allow to specify the triple of binary, initrd, and device-tree in boot
options.
Add the code to actually load the specified device-tree.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We already support creating a load option where the device-path
field contains the concatenation of the binary device-path and
optionally the device path of the initrd which we expose via the
EFI_LOAD_FILE2_PROTOCOL.
Allow to append another device-path pointing to the device-tree
identified by the device-tree GUID.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Allow appending a device-path to a device-path that contains an end node
as separator. We need this feature for creating boot options specifying
kernel, initrd, and dtb.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Prepare v2024.070-rc4
|
|
replace tpm2_supported_algorithms with an array of structures
relating algorithm names, to TCG id's, digest length and mask values.
While at it fix the tpm2_algorithm_to_mask to return the proper value.
Cc: Eddie James <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Fixes: 97707f12fdab ("tpm: Support boot measurements")
Signed-off-by: Tim Harvey <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Sughosh Ganu <[email protected]> says:
The following patch series adds support for version 2 of the FWU
metadata. The version 2 metadata structure is defined in the latest
revision of the FWU specification [1].
The earlier versions of these patches were migrating to a version 2
only support in U-Boot, similar to TF-A. However, based on feedback
from ST [2], this series has been updated to support both versions. A
platform would still be needed to enable one of the two versions of
metadata through a config symbol.
TF-A has code which reads the FWU metadata and boots the platform from
the active partition. TF-A has decided to migrate the FWU code to a
version 2 only support. These changes have been merged in upstream
TF-A.
These changes have been tested on the ST DK2 board, which uses the GPT
based partitioning scheme. Both V1 and V2 metadata versions have been
tested on the DK2 board.
These changes need to be tested on platforms with MTD partitioned
storage devices.
|
|
Transition the platform to either Trial State or Regular State on a
successful update. Do this by calling the fwu_state_machine_updates()
API function.
For version 1 of the FWU metadata, the transition to Trial State is
done by starting the Trial State counter, while for version 2, in
addition to the counter, the bank_state field of the FWU metadata is
also updated to Valid.
For transitioning the platform to Regular State, no action is needed
with version 1 of the FWU metadata structure, while for version 2, the
bank_state field is set to Accepted.
Signed-off-by: Sughosh Ganu <[email protected]>
Tested-by: Michal Simek <[email protected]>
|
|
Remove the redundant includes of u-boot/sha1.h, u-boot/sha256.h
and u-boot/sha512.h
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We should not pass GUIDs by value as this requires copying.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
