Now that oe-core moved to OpenSSL 4.0, the engine API is gone.
As a result uboot-mkimage's -N/--engine no longer work:
Failed to sign 'signature-1' signature node in 'conf-imx6dl-riotboard.dtb' conf node
uboot-mkimage Can't add hashes to FIT blob: -1
Error: Bad parameters for FIT image type
Usage: uboot-mkimage [-T type] -l image
-l ==> list image header information
-T ==> parse image file as 'type'
-q ==> quiet
A previous patch documented how provider-based PKCS#11 signing works.
Now make an engine option in FITIMAGE_MKIMAGE_EXTRA_ARGS a fatal error. It
has no effect anymore, so a recipe still setting it has not been
migrated; failing with a clear message beats mkimage's generic error
messages above.
Signed-off-by: Bastian Krause <bst@pengutronix.de>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Now that oe-core moved to OpenSSL 4.0, the engine API is gone.
As a result uboot-mkimage's -N/--engine no longer work:
Failed to sign 'signature-1' signature node in 'conf-imx6dl-riotboard.dtb' conf node
uboot-mkimage Can't add hashes to FIT blob: -1
Error: Bad parameters for FIT image type
Usage: uboot-mkimage [-T type] -l image
-l ==> list image header information
-T ==> parse image file as 'type'
-q ==> quiet
Document the provider-based setup instead: signing_create_uri_pem() wraps
the role's PKCS#11 URI in a PEM file that OpenSSL loads like a key file and
resolves through the PKCS#11 provider configured by signing_prepare().
mkimage looks for a key in
${FITIMAGE_SIGN_KEYDIR}/${FITIMAGE_SIGN_KEYNAME}.key, so store it there.
This way the existing mkimage invocations do not need to be touched.
Signed-off-by: Bastian Krause <bst@pengutronix.de>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
signing_extract_cert_der() and signing_extract_cert_pem() read the
certificate off the token with 'extract-cert <pkcs11-uri>'. extract-cert
reaches a pkcs11 token through the OpenSSL ENGINE API, which OpenSSL 4.0
removed; meta-oe's own extract-cert now errors "PKCS#11 URIs require
OpenSSL < 4.0" on such input. Both exporters are therefore broken on
OpenSSL 4.
signing_prepare() already configures the pkcs11 provider (OPENSSL_MODULES
plus a provider openssl.cnf), so read the certificate through it with
'openssl storeutl -certs' instead. The class is provider-based on both
OpenSSL 3 and 4, so this needs no version branching. Make _pem the
primitive (storeutl emits PEM) and derive _der from it.
storeutl -certs writes every certificate the URI matches; a signing role
URI is expected to pin a single object, and _der keeps the first cert
should more than one come back.
The class no longer invokes extract-cert; drop it from DEPENDS.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
signing_prepare() signs via the pkcs11 provider only: it writes a provider
openssl.cnf and uses OSSL_STORE for native provider access. Nothing invokes
the OpenSSL ENGINE API (no -engine), so the OPENSSL_ENGINES export and the
engines-3 directory check are dead code. The check even hard-fails
(return 1) when engines-3 is absent, which OpenSSL 4.0 no longer ships
(ENGINE API removed) - breaking signing outright although the provider path
is fine. Remove the engine export and the check.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Following the example in the comment as-is will lead to an error at
do_fitimage time:
The key ID is not a valid PKCS#11 URI
The PKCS#11 URI format is defined by RFC7512
The key ID is not a valid PKCS#11 URI
The PKCS#11 URI format is defined by RFC7512
PKCS11_get_private_key returned NULL
Failure loading private key from engine: error:40000064:pkcs11 engine::invalid id
uboot-mkimage Can't add hashes to FIT blob: -1
Strip the pkcs11: prefix to resolve this and save future users the
hassle.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
FITIMAGE_CONFIG_PREFIX is only used for configurations that contain a
kernel image, but not for mere overlay configurations.
This is inconsistent with the original kernel-fitimage.bbclass.
As the name may be hardcoded in the bootloader, add a new
FITIMAGE_CONFIG_FDTO_PREFIX to be able to customize the prefix for
device tree overlay configuration nodes as well.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Ensure that symbolic links (${IMAGE_LINK_NAME}) are created for both
sparse images, matching standard Yocto image deployment behavior
Signed-off-by: AshishKumar Mishra <emailaddress.ashish@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
dm-verity can use Reed-Solomon forward error correction (FEC) data
to transparently recover a limited number of corrupted blocks instead
of only detecting them. This can be useful for mitigating error-prone
storage.
We generate this FEC data as an option, controlled by VERITY_FEC
(default off, same behavior as before) and VERITY_FEC_ROOTS (number of
Reed-Solomon roots, default 2). The FEC data is appended to the hash
tree by default. If VERITY_IMAGE_FECDEV_SUFFIX is set, a separate file
with the given suffix will be used.
When enabled, the parameter file gains additional variables necessary
for correct DM table generation.
Recipes that do not set VERITY_FEC = "1" behave the same as before.
Signed-off-by: Andreas Zdziarstek <andreas.zdziarstek@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
OpenSSL 4.0 will drop support for engines and use providers instead.
To access SoftHSM and other PKCS#11 modules via the provider API, we
rely on https://github.com/latchset/pkcs11-provider, which is already
available as via pkcs11-provider recipe.
We enable this provider by using a specific OpenSSL config when signing.
This means that recipes inheriting this class can decide whether they
want to use the engine or provider to access the key.
SoftHSM seems to produce broken keys when calling the C_CopyObject, so
disable caching in the provider for now.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When creating sparse images, the RAW image is no longer needed in
some workflows such as Android and CI pipelines. These RAW images
can be multi-GB artifacts and consume significant disk space.
This change introduces a configuration option
`DELETE_RAWIMAGE_AFTER_SPARSE_CMD` which, when set to "1",
removes the RAW image after sparse image generation.
This reduces disk usage in builds where sparse images are the
final deliverables and RAW images are not required.
Default behavior is unchanged: RAW images are kept unless the
variable is explicitly enabled:
DELETE_RAWIMAGE_AFTER_SPARSE_CMD = "1" # Delete RAW image
DELETE_RAWIMAGE_AFTER_SPARSE_CMD = "0" # Default behavior
Signed-off-by: AshishKumar Mishra <emailaddress.ashish@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Since cryptsetup 2.8.0 [1], "veritysetup format" prints " [bytes]"
suffixes for "Data block size" and "Hash block size" parameters:
UUID:
Hash type: 1
Data blocks: 34655
Data block size: 4096 [bytes]
Hash blocks: 275
Hash block size: 4096 [bytes]
Hash algorithm: sha256
Salt: 8a8d8d807bd9838a80397a13b3bc13c55780ff1677ee4489366b17dab1b29316
Root hash: bd85312151dc5c69efce943038e0ac4b92e14d8954cce5d3cc90513837f854bf
This output is directly converted to a shell sourcable form in
"${DEPLOY_DIR_IMAGE}/<IMAGE_LINK_NAME>.verity-params" used to
create the desired block device via "dmsetup" during runtime. The unit
suffix becomes part of the VERITY_DATA_BLOCK_SIZE and
VERITY_HASH_BLOCK_SIZE variables, breaking its consumers:
/init: /verity-params: line 4: [bytes]: not found
/init: /verity-params: line 6: [bytes]: not found
verity root hash: bd85312151dc5c69efce943038e0ac4b92e14d8954cce5d3cc90513837f854bf
[ 3.323577] device-mapper: table: 253:0: verity: Invalid data device block size (-EINVAL)
[ 3.323595] device-mapper: ioctl: error adding target to table
[ 3.345301] /dev/dm-0: Can't lookup blockdev
Fix this by removing the unit suffixes from the values.
Ideally veritysetup should support machine-readable output, but that did
not spark joy on the maintainer's side [2] (at least in veritysetup
itself).
[1] commit f8788f34 ("Mark all sizes in status and dump output in the
correct units.")
[2] https://gitlab.com/cryptsetup/cryptsetup/-/issues/638
Signed-off-by: Bastian Krause <bst@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The env file holds the PKCS#11 uris, which include the pin to access
the database - in plaintext. Directly create the file (after it has
been remove) with the proper 'user RW only' permissions, to give only
the build-user access to this somewhat "security sensitive" file.
Note that the softhsm/sqlite3.db* is already 0x600.
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When BB_GIT_SHALLOW = "1" is used, the unpacked gir repository doesn't
exist in the download folder, and the class isn't able to inspect the
details of the repository.
Instead inspect the repository it the UNPACKDIR.
Beside this, since BitBake fetcher performs an actual initial shallow
clone of the repository when this feature is enabled, it is not possible
to determine the exact number of commits. Add a warning about this.
Reported-by: WXbet <WXbet@proton.me>
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
With https://github.com/OpenSC/OpenSC/pull/3174 which is part of 0.26.0,
OpenSC does not support reading the (DER-converted) object data from
stdin anymore.
However, OpenSC/pkcs11-tool also supports reading PEM files directly.
This we can use for simply replacing and simplifying the stdin piping in
signing_import_cert_from_pem().
Only for password-protected files we still have to use OpenSSL for
conversion, since OpenSC/pkcs11-tool currently doesn't have a mechanism
for providing passwords.
For these cases, we store the converted PEM into a simple temporary
file. This handling is sufficient, since SoftHSM import should be used
for example keys only and SoftHSM also doesn't protect the keys in any
way. Keys which actually need to be protected are stored in HSMs and
accessed via their PKCS#11 URIs.
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
With the now available set|get|has_ca functions to establish a CA link
between roles during their import, the
signing_import_cert_chain_from_pem can now be removed. As it had the
shortcoming of dynamically creating roles, which are harder to handle
then the manually/specifically setup CA roles.
This effectively reverts:
a825b85363 signing.bbclass: add certificate ca-chain handling
Reviewed-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add a method that returns a list of intermediary CA roles.
When using a complex PKI structure with for example "openssl cms",
these roles can then be iterated over adding in turn a '-certificate'.
Pseudo-code example:
for intermediate in $(signing_get_intermediate_certs 'FooBaa'); do
signing_extract_cert_pem $intermediate $intermediate.pem
CMD+=" --certificate=$intermediate.pem"
done
The typical use-case would be adding these intermediate certificates
to the CMS structure so that the relying party can build the chain
from the signing leaf certificate to the locally stored trusted CA
certificate.
Reviewed-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add a helper method to retrieve the root CA certificate for a given
role, by walking the chain that has been setup with
signing_import_set_ca up to the last element - which is the root.
Reviewed-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add a mechanism to establish a (metadata) link between roles and signer
certificates, in the form of a new 'ca' variable. It must point from one
role or cert to the signer certificate to preserve the leaf->intermediary->
root certificate relation.
With this additional mechanism, it would be now possible to import a
complex PKI tree of certificates and then later during usage of one
role, reconstruct the certificate chain from the leaf, through
multiple intermediary, and up to the root certificate.
Reviewed-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Refactor the two methods to import certificates from PEM/DER to be
usable independently from keymaterial that is linked to a role.
By having the import_cert_from methods create a storage location (aka
role) in the softhsm dynamically. This way certificates can - but
don't have to - be linked to a key, or can stand on their own if chain
of certificates from a PKI has to be managed.
Reviewed-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
filesystem so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With such a created image, placed into the correct folder (see [1]),
`systemd-sysext list` should be able to list the "extension" and
`systemd-sysext merge` should enable the overlay. On both commands a
preceding "SYSTEMD_LOG_LEVEL=debug" can aide in figuring out what is
amiss.
Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html
Link: https://0pointer.net/blog/testing-my-system-code-in-usr-without-modifying-usr.html
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Please see
https://git.yoctoproject.org/poky/commit/?id=4dd321f8b83afecd962393101b2a6861275b5265
for what changes are needed, and sed commands that can be used to make them en masse.
I've verified that bitbake -c patch world works with these, but did not run a world
build; the majority of recipes shouldn't need further fixups, but if there are
some that still fall out, they can be fixed in followups.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This bbclass is intended to be used via "INHERIT". The qemu.bbclass
is in classes-recipe. So we can't inherit qemu. We need to copy
QEMU_OPTIONS settings from qemu.bbclass and use oe.qemu to make things
work.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This reverts commit 24ff52ba3b.
The original patch was my bad. The patches for oe-core were re-worked,
but I forgot the recall this patch.
In fact, inheriting qemu is needed because it sets a clear barriar
for people to use qemu user mode. And the QEMU_OPTIONS settings
are also in qemu.bbclass.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Avoid inheriting qemu.bbclass and use oe.qemu.xxx instead.
Also, the 'qemu-native' dep is replaced by 'qemuwrapper-cross' for
PACKAGE_WRITE_DEPS. qemuwrapper-cross is the one that is actually
used by postints and it has 'qemu-native' in DEPENDS.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Files under it are source files. And if go/src locate under
/usr/lib, this will result in very long LD_LIBRARY_PATH causing
failure.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Using qemu to run non-elf executables such as shell scripts directly
is destined to fail. In such case, we check its interperter and try
out best to run it accordingly.
We'll also need to skip the "/etc" directory as files under it are
configuration files and init scripts. And the init script will
send SIGTERM and SIGKILL to all processes, giving users annoying
behavior.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
We need to ensure sysroot is available for this version check task,
otherwise, running binaries might fail because of lack of libraries
from sysroot.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
If users set CHECK_VERSION_PN for a recipe and its value is a single
'%', then it matches anything. So there's no point doing any further
check.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Avoid a single '(' in version. For example, we want to extract the
'2.30.31' instead of '2.30.31(2' for lvm2.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
If the kernel build type uses compression, the bootloader needs to take
care of decompression. This must be configured in the FIT image via
FITIMAGE_IMAGE_myimage[comp]. So warn if the FIT image kernel compression
is not specified in such a case.
Signed-off-by: Bastian Krause <bst@pengutronix.de>
Similar to e152f01d, this fixes another occurence of the config section
name to contain the 'conf_prefix'.
Luckily, this one is only debug output.
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
A given image type should be valid. Thus fail early here instead of
randomly failing later during mkimage call.
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
When no type is set, we simply pick 'kernel' as the default since it
is still the most common to be used for FIT images.
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
The 'image' name should be printed rather than the (unset) 'recipe'.
Also use f-strings for better readability.
Since a missing recipe configuration is fatal to a proper generation,
abort the parsing with bb.fatal instead of continuing with a broken
configuration.
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Add a mechanism to check mismatch between runtime version and build time version.
To use, add the following line to local.conf:
include conf/version-check.conf
Ideally, layers will have their own conf/version-check.conf to establish
some baseline, so that any future warning indicates some error. In such
case, users can use include_all:
include_all conf/version-check.conf
The basic idea is to use qemu to run executables at build time, extract
possible versions, and check if there's a mismatch found.
Python meta data and .pc files are also checked for quick match. This
is because such info are also easy to be checked by users.
check-version-mismatch.bbclass is the class that does the actual work.
A new variable, CHECK_VERSION_PV, is introduced. It defaults to ${PKGV},
but also allows override. This allows us to handle special cases in each
layer.
version-check.conf is the configuration file that makes this functionality
easier to use and draws some baseline. It contains some override settings
for some recipes. With these overrides, all recipes in oe-core are handled
well. All warnings are valid warnings.
Note that 'ps' is added to HOSTTOOLS in version-check.conf. This is because
we need 'ps' to find stale processes and then clean them.
The warnings are like below:
WARNING: time-1.9-r0 do_package_check_version_mismatch: Possible runtime versions ['UNKNOWN'] do not match recipe version 1.9
WARNING: python3-unittest-automake-output-0.2-r0 do_package_check_version_mismatch: Possible runtime versions ['0.1'] do not match recipe version 0.2
WARNING: pinentry-1.3.1-r0 do_package_check_version_mismatch: Possible runtime versions ['1.3.1-unknown'] do not match recipe version 1.3.1
...
There will be a data directory containing all details: tmp/check-version-mismatch.
This directory contains detailed data for each recipe that is built.
If users don't want it, they can set DEBUG_VERSION_MISMATCH_CHECK to 0.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
On some setups, the verity partition and the corresponding hash data are
handled separately. To account for this, a HASHDEV_SUFFIX is introduced
to divert the hash data to a separate image artifact. By default, this
suffix is equal to the image suffix, meaning that the hash data is
appended to the verity image, like before.
When the hash data is written to a separate file, the verity image is
padded with zeroes until its size is a multiple of block_size.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The bitbake fetcher dropped support for multiple revisions on a single
url. Update the gitpkgver code to match.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The functions related to signing the fitimage had missing quotations and
newlines. Without this punctuation, the signing class would fail to
generate a signed fitimage.
To test this change just create a fitImage using this class and set
FITIMAGE_SIGN to 1. The resulting fitImage its file should have one
property per line with quotes around the property values.
Signed-off-by: John Ripple <john.ripple@keysight.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When linking to capnproto from another project, cmake fails to
find this package with the following error:
| CMake Error at ${RECIPE_SYSROOT}/usr/lib/cmake/CapnProto/CapnProtoTargets.cmake:176 (message):
| The imported target "CapnProto::capnp_tool" references the file
|
| "${RECIPE_SYSROOT}/usr/bin/capnp"
|
| but this file does not exist. Possible reasons include:
To solve this, this change includes the following:
1. Add a patch that removes the files installed (and exported) in
${bindir} from the target build. The CMake file originally verified
that these files exist when another recipe tried to use it, however
the ${RECIPE_SYSROOT} does not contain the binaries in ${bindir},
so it failed quick in the do_configure step. (This alone is enough
to link against the cross-compiled libraries of capnproto successfully,
but code-generation from capnproto definition fails)
2. Add a new bbclass for capnproto. To cross-compile an application
that uses capnproto, the application needs to be linked against the
cross-compiled version of the libraries, however the native version
of the binaries need to be used to generate C++ code from the
capnproto definitions. This class sets the correct CMake arguments, to
use the capnproto binaries from the native package, instead of looking
for the non-existent cross-compiled binaries. (These variables can
be found in ${libdir}/cmake/CapnProto/CapnProtoConfig.cmake file)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Signed-off-by: Akash Hadke <akash.hadke27@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
shenlf
Bastian Krause
Johannes Schneider
Marcel Hellwig
Ahmad Fatoum
AshishKumar Mishra
Thomas Bonnefille
Andreas Zdziarstek
Fabian Pflug
Jan Luebbe
Gyorgy Sarvari
Enrico Jörns
Alexander Kanavin
Chen Qi
Erik Schumacher
Hains van den Bosch
Richard Purdie
John Ripple
Akash Hadke