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:
a825b853634 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 extract-cert wrapping helper functions, to easily extract
certificates again that had been previously imported into the softhsm.
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 24ff52ba3b73757cc0255a5b19822e2e4d3d4e0a.
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>
xserver-common was the last recipe to use this, so remove it.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The `panel-mipi-dbi.bbclass` can be used to build a firmware file for use
with the `panel-mipi-dbi` Linux driver.
The class uses the `mipi-dbi-cmd` from `panel-mipi-dbi-native` to
assemble a human readable list of init commands into a firmware file
for use with the `panel-mipi-dbi` Linux driver.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add a (more helpful) error message in case the Package-Name exceeds a
certain length which would have the softhsm tools error out.
The $PN is used as 'label' in the softhsm, which is a
"CK_UTF8CHAR paddedLabel[32]" in softhsm2-util.cpp,
so it must not be longer.
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add handling of ca-chains which can consist of more than one
certificate in a .pem file, which need to be split off, processed and
stored separately in the softhsm - as the tool-chain
signing.bbclass::signing_import_cert* -> softhsm -> 'extract-cert'
only supports one-per-file, due to using/expecting "plain" x509
in-/output.
The added signing_import_cert_chain_from_pem function takes a <role>
basename, and iterates through the input .pem file, creating numbered
<role>_1, _2, ... roles as needed.
Afterwards the certificates can be used or extracted one-by-one from
the softhsm, using the numbered roles; the only precondition - or
limitation - is that the PKI structure has to be known beforhand;
e.g. how many certificates are between leaf and root.
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The FIT image support in OE is quite limited:
1) No support to build an arbitrary number of FIT images since the FIT
image generation is tightly coupled to the kernel image.
2) A lot of U_BOOT-specific variables which may not be necessary for
other bootloaders.
3) No usage of the meta-oe signing.bbclass for signed FIT images.
This alternative class is added to solve the above-mentioned problems:
1) The class can be inherited by an arbitrary number of
<fit-image-name>.bb recipes to generate FIT images
2) No U_BOOT-specific variables are used
3) <fit-image-name>.bb recipes can prepend the do_fitimage() to
provide the key using the signing.bbclass e.g.:
do_fitimage:prepend() {
signing_prepare
signing_use_role "${FITIMAGE_SIGNING_KEY_ROLE}"
}
Then enable and configure signing as follows:
FITIMAGE_SIGN = "1"
FITIMAGE_MKIMAGE_EXTRA_ARGS = "--engine pkcs11"
FITIMAGE_SIGN_KEYDIR = "${PKCS11_URI}
This class is inspired by the meta-phytec fitimage.bbclass [1].
[1] https://git.phytec.de/meta-phytec/tree/classes/fitimage.bbclass
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add support to generate a dm-verity image and the parameters required to
assemble the corresponding table for the device-mapper driver. The latter will
be stored in the file ${DEPLOY_DIR_IMAGE}/<IMAGE_LINK_NAME>.verity-params.
Note that in the resulting image the hash tree data is appended to the contents
of the original image without an explicit superblock to keep things simple and
compact.
The above mentioned parameter file can be sourced by a shell to finally create
the desired blockdevice via "dmsetup" (found in meta-oe's recipe
"libdevmapper"), e.g.
. <IMAGE_LINK_NAME>.verity-params
dmsetup create <dm_dev_name> --readonly --table "0 $VERITY_DATA_SECTORS verity \
1 <dev> <hash_dev> \
$VERITY_DATA_BLOCK_SIZE $VERITY_HASH_BLOCK_SIZE \
$VERITY_DATA_BLOCKS $VERITY_DATA_BLOCKS \
$VERITY_HASH_ALGORITHM $VERITY_ROOT_HASH $VERITY_SALT \
1 ignore_zero_blocks"
As the hash tree data is found at the end of the image, <dev> and <hash_dev>
should be the same blockdevice in the command shown above while <dm_dev_name> is
the name of the to be created dm-verity-device.
The root hash is calculated using a salt to make attacks more difficult. Thus,
please grant each image recipe its own salt which could be generated e.g. via
dd if=/dev/random bs=1k count=1 | sha256sum
and assign it to the parameter VERITY_SALT.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The function signing_import_pubkey_from_pem is defined twice, one of
them should really be named signing_import_pubkey_from_der. Fix this and
while at it fix some argument names in the comments above the functions
as well.
Reported-by: Miklos Toth <Miklos.Toth@knorr-bremse.com>
Fixes: 4a6ac691f ("add signing.bbclass as infrastructure for build artifact signing")
Signed-off-by: Sascha Hauer <sha@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
"openssl rsa" works with RSA keys only. Use "openssl pkey" instead which
is a frontend that picks the right operation automatically and works
with RSA keys, eliptic curve keys and also DSA keys.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
OPENSSL_{MODULES,ENGINES,CONF} and SSL_CERT_{DIR,FILE} are currently
exported globally for any recipe that inherits signing. This not only
affects the tasks that use the signing infrastructure, but also unrelated
tasks like e.g. do_fetch. Avoid this by exporting the variables only
for these tasks that actually call signing_prepare.
This resolves a breakage I observed on Ubuntu 18.04, where the host
tool wget is called with the environment variables set and then fails
with a SSL error (exit code 5).
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When using the image type:
IMAGE_FSTYPES += " wic.sparse"
IMAGE_CLASSES += " image_types_sparse"
The following error arises:
Syntax error: Bad function name
So need to remove function in favor of variable.
Also remove IMAGE_NAME_SUFFIX as per:
https://git.openembedded.org/openembedded-core/commit/?id=26d97acc71379ab6702fa54a23b6542a3f51779c
Signed-off-by: Chris Dimich <chris.dimich@boundarydevices.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Fixes
DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
pipes is an alias for shlex therefore switch to using shlex
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This adds common infrastructure to access and used asymmetric keys to
sign build artifacts. The approach and implementation was presented at
the recent OpenEmbedded Workshop:
https://pretalx.com/openembedded-workshop-2023/talk/3C8MFF/
A working demo setup for verified boot based on qemu is available at
https://github.com/jluebbe/meta-code-signing.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
