This patch adds support for parsing ECDSA public keys from the device tree
blob (FDT) under the `/signature` node. The public key is expected to be
defined using:
- ecdsa,curve (e.g., "prime256v1", "secp384r1")
- ecdsa,x-point
- ecdsa,y-point
The implementation introduces:
- struct ecdsa_public_key to hold parsed key fields
- fdt_get_key() to parse the curve and coordinates from the FDT
- read_key_from_fdt() to convert the parsed values into an OpenSSL EC_KEY
- load_key_from_fdt() to support loading keys using required_keynode,
keyname hint, or fallback to scanning all subnodes under "/signature".
If "info->fdt_blob" is provided, the key is loaded from the FDT. Otherwise,
the code falls back to loading a PEM-formatted key from file as before.
This allows for ECDSA signature verification where the public key is
embedded in the FIT image device tree, useful for systems that require
signature validation without external files.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The LMB module has a bunch for API's which are used for allocating
memory. There are a couple of API's for requesting memory, and two
more for reserving regions of memory. Replace these different API's
with a single one, lmb_alloc_mem(). The type of allocation to be made
is specified through one of the parameters to the function.
Additionally, the two API's for reserving regions of memory,
lmb_reserve() and lmb_alloc_addr() are the same with one
difference. One can reserve any memory region with lmb_reserve(),
while lmb_alloc_addr() actually checks that the memory region being
requested is part of the LMB memory map. Reserving memory that is not
part of the LMB memory map is pretty futile -- the allocation
functions do not allocate memory which has not been added to the LMB
memory map.
This series also removes the functionality allowing for reserving
memory regions outside the LMB memory map. Any request for reserving a
region of memory outside the LMB memory map now returns an -EINVAL
error.
Certain places in the common code using the LMB API's were not
checking the return value of the functions. Checks have been added for
them. There are some calls being made from the architecture/platform
specific code which too do not check the return value. Those have been
kept the same, as I do not have the platform with me to check if it
causes any issues on those platforms.
In addition, there is a patch which refactors code in
lmb_overlaps_region() and lmb_can_reserve_region() so that both
functionalities can be put in a single function, lmb_overlap_checks().
Finally, a new patch has been added which checks the return value of
the lmb allocation function before copying the device-tree to the
allocated address.
Link: https://lore.kernel.org/r/20250617104346.1379981-1-sughosh.ganu@linaro.org
[trini: Rework arch/arm/mach-snapdragon/board.c merge]
Signed-off-by: Tom Rini <trini@konsulko.com>
The functions that handle allocation requests check if a region of
memory overlaps with a used region. This is done through
lmb_overlaps_region(). Similar checks are done for reservation
requests made to the LMB module, where the caller asks specifically
for a particular region of memory. These checks are being done through
lmb_can_reserve_region().
There are subtle differences in the checking needed for allocation
requests, as against reservation requests. In the former, it is only
needed to be checked if a region is overlapping with an existing
used region, and return as soon as an overlap is found. For
reservation request checks, because U-Boot allows for re-use of in-use
regions with a particular memory attribute, this check has to iterate
through all the regions that might overlap with the requested region,
and then check that the necessary conditions are met to allow for the
overlap.
Combine these two checks in a single function, lmb_overlap_checks() as
both lmb_overlaps_region() and lmb_can_reserve_region() are pretty
similar otherwise.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There is no need to have two separate API's for freeing up memory. Use
a single API lmb_free() to achieve this.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.
Fixes: 942c8c8e66 ("rsa: Add rsa_verify_openssl() to use openssl for host builds")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Add support of optional shortname for parameter 'type' of gpt
command (limited by UUID_STR_LEN) and a separate 'description'
for UID format "%pUs" used in 'part list' output.
When 'description' is absent in list_guid[], the optional
shortname is used as fallback.
Many partition types for EFI have no shortcut yet, but only
description as they are only used to display information.
This patch also restores the "system" as short name for EFI
System Partition (ESP).
Fixes: d54e1004b8 ("lib/uuid.c: use unique name for PARTITION_SYSTEM_GUID")
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
E Shattow <e@freeshell.de> says:
Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.
There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.
External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.
Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de
Rasmus Villemoes <ravi@prevas.dk> says:
There's really no reason for the gd pointer to have the volatile
qualifier.
In fact, I claim that it's completely unnecessary and just pessimizes
code generation and forces ugly casts in lots of places. For example,
see the casts in drivers/core/tag.c where elements are added to
gd->dm_taglist, or a helper such as cyclic_get_list() that should not
be needed.
Also, it is what ends up standing in the way of an otherwise
innocent code cleanup of list.h:
https://lore.kernel.org/u-boot/20250522165656.GB2179216@bill-the-cat/
Note that riscv, x86 as well as arm64 with LTO enabled has not had
this volatile qualifier, so it's unlikely there's any generic code
that depends on it.
Link: https://lore.kernel.org/r/20250604195612.2312979-1-ravi@prevas.dk
The global gd pointer is no longer volatile-qualified, so drop that
qualifier from these bookkeeping variables.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The global gd pointer is no longer volatile-qualified, so drop that
qualifier from these bookkeeping variables.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
%s/data that change/data that changes/
%s/cannot be used has/cannot be used for/
%s/Otherwise/Otherwise,/
%s/allows better measurement/allows for better measurement/
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Update definition of _debug_uart_putc to static inline.
This will allow to avoid compilation warnings about unused code
after introduction of patch changing debug uart functions to
dummies if CONFIG_DEBUG_UART is not set.
This also matches the instructions in include/debug_uart.h and
provides consistency with implementations for other platforms.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tom Rini <trini@konsulko.com> says:
Hey all,
Related to my other series I've posted recently on cleaning up some
headers, this series here is the result of at least lightly auditing the
#includes used in include/[a-m]*.h. This ignores subdirectories, as at
least in part I think the top-level includes we've constructed are the
most likely places to have some extra transitive include paths. I'm sure
there's exceptions and I'll likely audit deeper once this first pass is
done. This only gets as far as "include/m*.h" because I didn't want this
to get too big. This also sets aside <miiphy.h> and <phy.h>. While
miiphy.h does not directly need <phy.h> there are *so* many users and I
think I had half of the tree just about not building when I first tried.
It might be worth further investigation, but it might just be OK as-is.
Link: https://lore.kernel.org/r/20250521230119.2084088-1-trini@konsulko.com
There are only a few things found in <mtd.h> today. Go through and audit
the C files which include <mtd.h> and remove it when not required. Then,
add it to the files which had either missed it or had an indirect
inclusion of it.
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point in time, <ide.h> provides the IDE_BUS macro and the
function prototype for ide_set_reset, which is used with IDE_RESET. The
only files which should include this header are the ones that either use
that macro or that function. Remove <blk.h> from <ide.h> and remove
<ide.h> from places which do not need it.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is useful to format a string into a buffer, with the sizing handled
automatically. Add a function for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to copy an abuf, to allow changes while
preserving the original. Add a function for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct appears in various places. Reduce code size by adding a
function for it.
It inits the abuf, then allocates it to the requested size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tom Rini <trini@konsulko.com> says:
Hey all,
This is a v3 of Simon's series[1] and depends on the series[2] I posted
the other day that removes <env.h> from <command.h>. With this series
done, I believe we've tackled all of the current cases of headers which
include <env.h> without directly needing it. Much of this series is in
fact Simon's v2 with the main differneces being:
- Removing <env.h> from <net.h> at the end
- Removing env_to_ip() given how little it's used rather than shuffling
around where it's declared and un-inline'ing it. For a rarely used
helper, this ends up being cleaner I think. Especially looking at some
of the users (which called env_get repeatedly). If there's strong
opinion here about using the other method[3] we can do that instead.
- Setting aside for now how to handle CMD_ELF=y and NO_NET=y because
today it's actually fine as we unconditionally build lib/net_utils.c
where string_to_ip() is defined. I'm unsure if a further series is
warranted here or not. We rely on link-time optimization to keep code
readable too.
[1]: https://lore.kernel.org/all/20250501010456.3930701-1-sjg@chromium.org
[2]: https://lore.kernel.org/all/20250514225002.15361-1-trini@konsulko.com
[3]: https://lore.kernel.org/all/20250501010456.3930701-23-sjg@chromium.org
Link: https://lore.kernel.org/r/20250515234154.1859366-1-trini@konsulko.com
Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # android, bcb
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # spawn
Signed-off-by: Tom Rini <trini@konsulko.com>
Rasmus Villemoes <ravi@prevas.dk> says:
This started as a rather simple patch, 1/12, adding the ability to
more conveniently do regex matching in shell.
But with that, it became very easy to see what the slre library can
and especially what it cannot do, and that way I found both outright
bugs and a "wow, doesn't it support that syntax" gotcha. I couldn't
find any tests ('git grep slre -- test/' was empty), so I added a
small test suite and tweaked slre.c.
Link: https://lore.kernel.org/r/20250513084034.654865-1-ravi@prevas.dk
When trying to use U-Boot's regex facility, it is a rather large
gotcha that [a-z] range syntax is not supported. It doesn't require a
lot of extra code to implement that; we just let the regular parsing
emit the start and end literal symbols as usual, and add a new
"escape" code RANGE.
At match time, this means the code will first just see an 'a' and try
to match that, and only then recognize that it's actually part of a
range and then do the 'a' <= ch <= 'z' test.
Of course, this means that a - in the middle of a [] pair no longer
matches a literal dash, but I highly doubt anybody relies on
that. Putting it first or last, or escaping it with \, as in most
other RE engines, continues to work.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
At the compile stage, the anyof() function clearly intends to handle escape
sequences like \d (for digits) inside square brackets, since the logic
emits a 0 byte followed by the code representing the character
class (NONSPACE, SPACE or DIGIT).
However, this is not handled in the corresponding match helper
is_any_of(); it just naively loops over all the bytes in the ->data
array emitted by anyof() and compares those directly to the current
character. For example, this means that the string "\x11" (containing
the single character with value 17) is matched by the regex "[#%\d]",
because DIGIT happens to be 17.
Fix that by recognizing a zero byte as indicating something special
and act accordingly. In order not to repeat the "increment *ofs and
return 1" in all places, put those two lines after a new match: label.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
As preparation for fixing the handling of backslash-escapes used
inside a character class, refactor is_any_but() to be defined in terms
of is_any_of() so we don't have to repeat the same logic in two places.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The regex '^a|b' means "does the string start with a, or does it have
a b anywhere", not "does the string start with a or b" (the latter
should be spelled '^[ab]' or '^(a|b)'). It should match exactly the
same strings as 'b|^a'. But the current implementation hard-codes an
assumption that when the regex starts with a ^, the whole regex must
match from the beginning, i.e. it only attempts at offset 0.
It really should be completely symmetrical to 'b|c$' ("does it have a
b anywhere or end with c?"), which is treated correctly.
Another quirk is that currently the regex 'x*$', which should match
all strings (because it just means "does the string end
with 0 or more x'es"), does not, because in the unanchored case we
never attempt to match at ofs==len. In the anchored case, '^x*$', this
works correctly and matches exactly strings (including the empty
string) consisting entirely of x'es.
Fix both of these issues by dropping all use of the slre->anchored
member and always test at all possible offsets. If the regex does have
a ^ somewhere (including after a | branch character), that is
correctly handled by the match engine by only matching when *ofs is 0.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
This value provides an offset for all image-pos values in the image.
Read it on startup so that we can take account of it when calculating
positions.
Signed-off-by: Simon Glass <sjg@chromium.org>
The EFI boot manager relies on having an IP address before trying to
boot an EFI HTTP(s) boot entry. However, defining it as a boot or
pre-boot command is not always the right answer since it will
unconditionally add delay to the board boot, even if we don't boot
over the network.
So let's do a DHCP request from the boot manager, if 'ipaddr' is
empty and fail early if we don't have an address.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
This exported symbol has a very generic name. Rename it to indicate that
it relates to EFI and device-paths.
Fix checkpatch warnings related to use of multiple assignments.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
These functions are useful for the EFI app. As a first step towards
making these available outside lib/efi_loader, create a separate header
file and include it where needed. Add proper comments to the functions,
since many are missing at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Sean Edmond <seanedmond@microsoft.com> says:
In our datacenter application, a single DHCP server is servicing 36000+ clients.
Improvements are required to the DHCPv4 retransmission behavior to align with
RFC and ensure less pressure is exerted on the server:
- retransmission backoff interval maximum is configurable
(environment variable bootpretransmitperiodmax)
- initial retransmission backoff interval is configurable
(environment variable bootpretransmitperiodinit)
- transaction ID is kept the same for each BOOTP/DHCPv4 request
(not recreated on each retry)
For our application we'll use:
- bootpretransmitperiodmax=16000
- bootpretransmitperiodinit=2000
A new configuration BOOTP_RANDOM_XID has been added to enable a randomized
BOOTP/DHCPv4 transaction ID.
Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous
patch was accepted. A new patch fixes a possible double free() and
addresses latest review comments.
Link: https://lore.kernel.org/r/20240509023918.2504185-1-seanedmond@microsoft.com
This patch introduces 3 improvements to align with RFC 951:
- retransmission backoff interval maximum is configurable
- initial retranmission backoff interval is configurable
- transaction ID is kept the same for each BOOTP/DHCPv4 request
In applications where thousands of nodes are serviced by a single DHCP
server, maximizing the retransmission backoff interval at 2 seconds (the
current u-boot default) exerts high pressure on the DHCP server and
network layer.
RFC 951 “7.2. Client Retransmission Strategy” states that the
retransmission backoff interval should be limited to 60 seconds. This
patch allows the interval to be configurable using the environment
variable "bootpretransmitperiodmax"
The initial retranmission backoff period defaults to 250ms, which is
also too small for these scenarios with many clients. This patch makes
the initial retransmission interval to be configurable using the
environment variable "bootpretransmitperiodinit".
Also, on a retransmission it is not expected for the transaction ID to
change (only the 'secs' field should be updated). Let's save the
transaction ID and use the same transaction ID for each BOOTP/DHCPv4
exchange.
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
The formatting with %pa / %pap behaves like %x, which results in an
incorrect value being output. To improve this, a new fine-tuning
Kconfig SPL_USE_TINY_PRINTF_POINTER_SUPPORT for pointer formatting
has been added. If it is enabled, the output of %pa / %pap should
be correct, and if it is disabled, the pointer formatting is
completely unsupported. In addition to indicate unsupported formatting,
'?' will be output. This allows enabling pointer formatting only
when needed. For SPL_NET it is selected by default. Then it also
supports the formatting with %pm, %pM and %pI4.
In summery this level of %p support for tiny printf is possible now:
1) The standard tiny printf won't have support for pointer formatting.
So it doesn't print misleading values for %pa, instead '?' will be
output:
%p => ?
%pa => ?a
%pap => ?ap
2) If SPL_USE_TINY_PRINTF_POINTER_SUPPORT is enabled or DEBUG is defined
tiny printf supports formatting %p and %pa / %pap.
3) If SPL_NET is enabled the support of pointers is extended
for %pm, %pM and %pI4.
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Functions called from EFI applications should not do console output.
Refactor the wget code to implement this requirement. The wget_http_info
struct is used to hold the boolean that signifies whether the output is
allowed or not.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We don't want ANSI escape-sequences written in tests since it is a pain
to check the output with ut_assert_nextline() et al.
Provide a way to tests to request that these characters not be sent.
Add a proper function comment while we are here, to encourage others.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Linux changed the behaviour of strim() so that a string with only spaces
reduces places the terminator at the start of the string, rather than
returning a pointer to the end of the string.
Bring in this version, from Linux v6.14
Add a comment about the new behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Imitate in dtbdump what initrddump does for color,
newlines and input handling. The output parsing in
the CI is strict and with the current output the CI
is not recongnizing the prompt '=>'.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently, when decompressing a gzip-compressed image during bootm, a
generic error such as "inflate() returned -5" is shown when the buffer is
too small. However, it is not immediately clear that this is caused by
CONFIG_SYS_BOOTM_LEN being too small.
This patch improves error handling by:
- Detecting Z_BUF_ERROR (-5) returned from the inflate() call
- Suggesting the user to increase CONFIG_SYS_BOOTM_LEN when applicable
- Preserving the original return code from zunzip() instead of overwriting
it with -1
By providing clearer hints when decompression fails due to insufficient
buffer size, this change helps users diagnose and fix boot failures more
easily.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
