To support passing specific commands defined in enum imx8image_cmd to
the imx8image_copy_image() function, this patch introduces a new entry
type nxp-imx9image. This entry generates a plain text data file
containing the relevant commands, enabling flexible configuration during
image creation.

Signed-off-by: Alice Guo <alice.guo@nxp.com>

Add new etype which generates the Renesas R-Car Gen4 SA0 header.
This header is placed at the beginning of SPI NOR and describes
where should data from SPI NOR offset 0x40000 be loaded to, and
how much data should be loaded there. In case of U-Boot, this is
used to load SPL and possibly other payload(s) into RT-VRAM.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Quentin Schulz <foss+uboot@0leil.net> says:

I misunderstood the documentation and put the signing key in a keys/
directory while setting key-name-hint property in the signature node and
u-boot-spl-pubkey-dtb to a path.

mkimage doesn't fail if it cannot find the public key when signing a
FIT but returns something on stderr to notify the user it couldn't find
the key. The issue is that bintool currently discards stderr if the
command successfully returns, so the FIT is not signed AND the user
isn't made aware of it unless the image is manually inspected.

mkimage does fail when trying to insert a public key in a DTB if it
isn't found but we can have a better error message.

Link: https://lore.kernel.org/r/20250418-binman-pubkey-dir-v2-0-b6b90a765ffe@cherry.de

key-name-hint property in u-boot-spl-pubkey-dtb binman entry may contain
a path instead of a filename due to user mistake.

Because we currently assume it is a filename instead of a path, binman
will find the full path to the key based on that path, and return the
dirname of the full path but keeps the path in key-name-hint instead of
stripping the directories from it.

This means mkimage will fail with the following error message if we have
key-name-hint set to keys/dev:

binman: Error 1 running 'fdt_add_pubkey -a sha256,rsa2048 -k /home/qschulz/work/upstream/u-boot/keys -n keys/dev -r conf /home/qschulz/work/upstream/u-boot/build/ringneck/u-boot-spl-dtbdhsfx3mf': Couldn't open RSA certificate: '/home/qschulz/work/upstream/u-boot/keys/keys/dev.crt': No such file or directory

Let's make it a bit more obvious what the error is by erroring out in
binman if a path is provided in key-name-hint (it is named key-name-hint
and not key-path-hint after all).

Fixes: 5609843b57a4 ("binman: etype: Add u-boot-spl-pubkey-dtb etype")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

mkimage doesn't fail if it cannot find the public key but it prints to
stderr. Considering that btool.run() discards stderr, it means binman
happily returns an unsigned FIT and doesn't tell you something went
wrong.

Binman will actually find the file if there's a path in the
key-name-hint property but the current logic expects key-name-hint to be
a filename and thus returns the dirname of the found path for the key,
but with the original key-name-hint appended. This means we can have the
following:

- key-name-hint = "keys/dev"
- name = "/home/qschulz/work/upstream/u-boot/keys/"

so we pass /home/qschulz/work/upstream/u-boot/keys/ to the -k option of
mkimage but the FIT still contains "keys/dev" in key-name-hint which
means mkimage will try to find the key at
/home/qschulz/work/upstream/u-boot/keys/keys/, which doesn't exist.

Let's assume paths are simply not supported (it is named key-name-hint
and not key-path-hint after all) and raise an error if the property
contains a path so that the build fails and not quietly.

Fixes: 133c000ca334 ("binman: implement signing FIT images during image build")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Background:

I have several customers that will be using a certain remote signing
service for signing their images, in order that the private keys are
never exposed outside that company's secure servers. This is done via
a pkcs#11 interface that talks to the remote signing server, and all
of that works quite well.

However, the way this particular signing service works is that one
must upfront create a "signing session", where one indicates which
keys one will use and, importantly, how many times each key will (may)
be used. Then, depending on the keys requested and the customer's
configuration, one or more humans must authorize that signing session
So for example, if official release keys are to be used, maybe two
different people from upper management must authorize, while if
development keys are requested, the developer himself can authorize
the session.

Once authorized, the requester receives a token that must then be used
for signing via one of the keys associated to that session.

I have that integrated in Yocto in a way that when a CI starts a BSP
build, it automatically works out which keys will be needed (e.g. one
for signing U-Boot, another for signing a kernel FIT image) based on
bitbake metadata, requests an appropriate signing session, and the
appropriate people are then notified and can then look at the details
of that CI pipeline and confirm that it is legitimate.

The problem:

The way mkimage does FIT image signing means that the remote server
can be asked to perform a signature an unbounded number of times, or
at least a number of times that cannot be determined upfront. This
means that currently, I need to artificially say that a kernel key
will be used, say, 10 times, even when only a single FIT image with
just one configuration node is created.

Part of the security model is that once the number of signings using a
given key has been depleted, the authorization token becomes useless
even if somehow leaked from the CI - and _if_ it is leaked/compromised
and abused before the CI has gotten around to do its signings, the
build will then fail with a clear indication of the
compromise. Clearly, having to specify a "high enough" expected use
count is counter to that part of the security model, because it will
inevitably leave some allowed uses behind.

While not perfect, we can give a reasonable estimate of an upper bound
on the necessary extra size by simply counting the number of hash and
signature nodes in the FIT image.

As indicated in the comments, one could probably make it even more
precise, and if there would ever be signatures larger than 512 bytes,
probably one would have to do that. But this works well enough in
practice for now, and is in fact an improvement in the normal case:
Currently, starting with size_inc of 0 is guaranteed to fail, so we
always enter the loop at least twice, even when not doing any signing
but merely filling hash values.

Just in case I've missed anything, keep the loop incrementing 1024
bytes at a time, and also, in case the estimate turns out to be over
64K, ensure that we do at least one attempt by changing to a do-while
loop.

With a little debug printf, creating a FIT image with three
configuration nodes previously resulted in

  Trying size_inc=0
  Trying size_inc=1024
  Trying size_inc=2048
  Trying size_inc=3072
  Succeeded at size_inc=3072

and dumping info from the signing session (where I've artifically
asked for 10 uses of the kernel key) shows

      "keyid": "kernel-dev-20250218",
      "usagecount": 9,
      "maxusagecount": 10

corresponding to 1+2+3+3 signatures requested (so while the loop count
is roughly linear in the number of config nodes, the number of
signings is quadratic).

With this, I instead get

  Trying size_inc=3456
  Succeeded at size_inc=3456

and the expected

      "keyid": "kernel-dev-20250218",
      "usagecount": 3,
      "maxusagecount": 10

thus allowing me to set maxusagecount correctly.

Update a binman test case accordingly: With the previous behaviour,
mkimage would try size_inc=0 and then size_inc=1024 and then
succeed. With this patch, we first try, and succeed, with 4*128=512
due to the four hash nodes (and no signature nodes) in 161_fit.dts, so
the image ends up 512 bytes smaller.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>

Moteen Shah <m-shah@ti.com> says:

In the U-Boot pre-relocation stage, if the parent node lacks
bootph-all/bootph-some-ram property and the driver lacks a pre-reloc
flag, all of its subsequent subnodes gets skipped over from driver
binding—even if they have a bootph* property.

This series addresses the issue by scanning through all the nodes during
build time and propagating the applicable  property to all of its supernode.

Link: https://lore.kernel.org/r/20250516114148.3862114-1-m-shah@ti.com

Add a testcase to ensure that scan_and_prop_bootph() actually
propagates bootph-* properties to supernodes.

Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

When external blobs are marked optional, they should not cause a
build to fail. Extend the test cases for FitTeeOsOptional and
ExtblobOptional.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>

Some test cases don't use _DoTestFile directly which accepts
allow_fake_blobs. However, they specifically test functionality that
requires external blobs not to be faked. Extend the _DoReadFileDtb
signature to allow passing that option to _DoTestFile.

Also fix tests that require non-faked ext blobs.
By default, external blobs are faked. Some tests care only about more
basic functionality. In those cases no external blobs should be faked.
That would trigger a different (binman) case which is not in scope for
those particular tests.
Thus, disable faked blobs for those test cases.

Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>