Move the signing-related test data (keys, certificates, OpenSSL and
SoftHSM2 configuration, dummy engine source) into the fit/ subdirectory
alongside the FIT DTS test files. Drop the 340_ prefix from files that
had it. Update the Makefile and all ftest.py references.

Signed-off-by: Simon Glass <simon.glass@canonical.com>

This adds a test that signs a FIT and verifies the signature with
fit_check_sign.

OpenSSL engines are typically for signing with external HW so it's not
that straight-forward to simulate.

For a simple RSA OpenSSL engine, a dummy engine with a hardcoded RSA
4096 private key is made available. It can be selected by setting the
OpenSSL engine argument to dummy-rsa-engine. This can only be done if
the engine is detected by OpenSSL, which works by setting the
OPENSSL_ENGINES environment variable. I have no clue if dummy-rsa-engine
is properly implementing what is expected from an RSA engine, but it
seems to be enough for testing.

For a simple PKCS11 engine, SoftHSMv2 is used, which allows to do PKCS11
without specific hardware. The keypairs and tokens are generated on the
fly. The "prod" token is generated with a different PIN (1234 instead of
1111) to also test MKIMAGE_SIGN_PIN env variable while we're at it.

Binman will not mess with the local SoftHSMv2 setup as it will only use
tokens from a per-test temporary directory enforced via the temporary
configuration file set via SOFTHSM2_CONF env variable in the tests. The
files created in the input dir should NOT be named the same as it is
shared between all tests in the same process (which is all tests when
running binman with -P 1 or with -T).

Once signed, it's checked with fit_check_sign with the associated
certificate.

Finally, a new softhsm2_util bintool is added so that we can initialize
the token and import keypairs. On Debian, the package also brings
libsofthsm2 which is required for OpenSSL to interact with SoftHSMv2. It
is not the only package required though, as it also needs p11-kit and
libengine-pkcs11-openssl (the latter bringing the former). We can detect
if it's properly installed by running openssl engine dynamic -c pkcs11.
If that fails, we simply skip the test.
The package is installed in the CI container by default.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

Fix the check for the __bss_size symbol, since it may be 0. Unfortunately
there was no test coverage for this.

Signed-off-by: Simon Glass <sjg@chromium.org>

The current support for updating variables in a binary is hard-coded to
work with U-Boot:

- It assumes the image starts at __image_copy_start
- It uses the existing U-Boot-specific entry types

It is useful for other projects to use these feature.

Add properties to enable writing symbols for any blob, a way of specifying
the base symbol and a way of providing the ELF filename to allow symbol
lookup to take place.

With this it is possible to update a Zephyr image, such as zephyr.bin
after it has been built.

Signed-off-by: Simon Glass <sjg@chromium.org>

Enabling CONFIG_BINMAN makes binman run after a build to package any
images specified in the device-tree. It also enables a mechanism for
SPL/TPL to declare and use special linker symbols that refer to other
entries in the same binman image. A similar feature that gets this info
from the device-tree exists for U-Boot proper, but it is gated behind a
CONFIG_BINMAN_FDT unlike the symbols.

Confusingly, CONFIG_SPL/TPL_BINMAN_SYMBOLS also exist. These configs
don't actually enable/disable the symbols mechanism as one would expect,
but declare some symbols for U-Boot using this mechanism.

Reuse the BINMAN_SYMBOLS configs to make them toggle the symbols
mechanism, and declare symbols for the U-Boot phases in a dependent
BINMAN_UBOOT_SYMBOLS config. Extend it to cover symbols of all phases.
Update the config prompt and help message to make it clearer about this.
Fix binman test binaries to work with CONFIG_IS_ENABLED(BINMAN_SYMBOLS).

Co-developed-by: Peng Fan <peng.fan@nxp.com>
[Alper: New config for phase symbols, update Kconfigs, commit message]
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>

Add a file that has two text sections at different addresses, so we can
test this behaviour in binman, once added.

Signed-off-by: Simon Glass <sjg@chromium.org>

WIth EFI we must embed the devicetree in an ELF image so that it is loaded
as part of the executable file. We want it to include the binman
definition in there also, which in some cases cannot be created until the
ELF (u-boot) is built. Add an option to binman to support writing the
updated dtb to the ELF file u-boot.out

This is useful with the EFI app, which is always packaged as an ELF file.

Signed-off-by: Simon Glass <sjg@chromium.org>

Binman needs to be able to update the contents of an ELF file after it has
been build. To support this, add a function to locate the position of a
symbol's contents within the file.

Fix the comments on bss_data.c and Symbol while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>

These test files are currently "intended for use on x86 hosts", but most
of the tests using them can still pass when cross-compiled to x86 on an
arm64 host.

This patch enables non-x86 hosts to run the tests by specifying a
cross-compiler via CROSS_COMPILE. The list of variables it sets is taken
from the top-level Makefile. It would be possible to automatically set
an x86 cross-compiler with a few blocks like:

    ifneq ($(shell i386-linux-gnu-gcc --version 2> /dev/null),)
    CROSS_COMPILE = i386-linux-gnu-
    endif

But it wouldn't propagate to the binman process calling this Makefile,
so it's better just raise an error and expect 'binman test' to be run
with a correct CROSS_COMPILE.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

A recent change adjusted the symbol calculation to work on x86 but broke
it for Tegra. In fact this is because they have different needs.

On x86 devices the code is linked to a ROM address and the end-at-4gb
property is used for the image. In this case there is no need to add the
base address of the image, since the base address is already built into
the offset and image-pos properties.

On other devices we must add the base address since the offsets start at
zero.

In addition the base address is currently added to the 'offset' and 'size'
values. It should in fact only be added to 'image-pos', since 'offset' is
relative to its parent and 'size' is not actually an address. This code
should have been adjusted when support for 'image-pos' and 'size' was
added, but it was not.

To correct these problems:
- move the code that handles adding the base address to section.py, which
  can check the end-at-4gb property and which property
  (offset/size/image-pos) is being read
- add the base address only when needed (only for image-pos and not if the
  image uses end-at-4gb)
- add a note to the documentation
- add a separate test to cover x86 behaviour

Fixes: 15c981cc (binman: Correct symbol calculation with non-zero image base)

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>