| Age | Commit message (Collapse) | Author |
|---|
|
After the using inherit_defer for the image classes in oe-core commit
451363438d38 ("classes/recipes: Switch to use inherit_defer"),
the using of anonymous python function in dm-verity-img.bbclass to
set the IMAGE_FSTYPES doesn't work anymore. The reason is that
image.bbclass also use anonymous python function to add the do_image_xxx
task for the corresponding filesystem type. The anonymous function in
dm-verity-img.bbclass is evaluated much later than the one in
image.bbclass. Then the task such as do_image_vhash will not be added
as we expect. So we choose to use "+=" to set the IMAGE_FSTYPES.
The populate_sdk_ext.bbclass may generate a dependency list like below:
core-image-minimal.do_sdk_depends -> lib32-core-image-minimal.do_image_vhash
So we also need to make sure the do_image_vhash task for the multilib
filesystem is added.
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
After the oe-core commit 26d97acc7137 ("image-artifact-names: include
${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
${IMAGE_LINK_NAME}"), the image names have changed from
core-image-minimal-qemux86-64-20230307181808.rootfs.ext4
core-image-minimal-qemux86-64.ext4
to
core-image-minimal-qemux86-64.rootfs-20230307181456.ext4
core-image-minimal-qemux86-64.rootfs.ext4
Adjust the images name used by dm-verity according to this change.
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
If image recipe A wants to embed another image B which used
dm-verity-img.bbclass and generated the .wks file, then
recipe B must deploy everything to IMGDEPLOYDIR but recipe A
finds the output from DM_VERITY_DEPLOY_DIR = "${DEPLOY_DIR_IMAGE}".
Now both A and B images can use dm-verity-img.bbclass.
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Reviewed-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
It is embedded into IMAGE_NAME since poky master branch commit
6f6c79029bc2020907295858449c725952d560a1
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Build host may not have bc.
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Export the dynamic build data for consumption in wic image generation.
It can either be included directly or manually parsed for useful chunks
in custom configurations people end up making.
For convenience, it is placed alongside the work-shared/dm-verity dir
where we already store the plain environment file and the veritysetup
formatting argument that was used.
There is a subtle thing going on here with respect to using an include,
which warrants a mention. The wic (wks.in) stuff only has access to
normal Yocto/OE/bitbake variables.
So, instead of a fragment, say if you had:
DM_VERITY_ROOT_HASH = "__not_set__"
and then later, did a:
d.setVar("DM_VERITY_ROOT_HASH", value)
after the image was built, and the hash was known - that seems sane.
But the problem is that once you do that, your variables are tracked
by default, and bitbake/lib/bb/siggen.py will be angry with you for
changing metadata during a build. In theory one should be able to avoid
this with BB_BASEHASH_IGNORE_VARS and "vardepsexclude" but it means more
exposed variables, and as much as I tried, I couldn't get this to work.
Creating a fragment with the dynamic data for inclusion avoids all that.
The wks template itself remains static, and hence doesn't trigger warns.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
There are essentially two ways for dealing with where to put the hash
data for dm-verity block integrity checks.
You can store both in a single partition, by using ~95% of the storage
space for the filesystem and the remaining 5% tail for the hash, or you
can use a completely separate partition (or even device) for storing the
hash data elsewhere.
Method A relies on using a hash offset argument during creation, which
is generally OK from a scripted use case but is error prone when run
from the command line and the offset calculated manually.
Method B has the advantage of using the basic partition/device
compartmentalization of the kernel to ensure the fs data doesn't
overwrite the hash or vice versa. It takes any possible errors due to
math miscalculations completely off the table.
At the moment, our current support is hard coded to only support the
offset method A. Here we add support for separate hash as per B.
As multiple partitions are now in play, we use the UUID creation
standard adopted by the systemd/verity community which implicitly links
the root and hash partitions by splitting the top roothash in two for
the UUIDs of the components.
This change optionally creates the separate hash file but no examples
use it yet. Further commits will implement an example.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
We already have this directory to save the environment variable settings
so they can be copied into the initramfs for runtime setup.
There are quite a few veritysetup args, and the nature of storing the
hash data after the filesystem data in an "oversized" partition can be
error prone due to rounding, fencepost errors, etc.
Save a copy of what we used for ease of debug inspection, and for basic
cut and paste use in experimentation and tweaking.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
In making changes to the existing veritysetup arg list, it is harder to
see what the proposed change is since they are are glued together on one
long line. Break them up so reviewing future unified diffs will be more
easy to visually parse.
This also makes it easier to temp. dump the args to a file for debugging.
In theory this should have no functional change.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
When using the kernel module parameter "dm-mod.create=" [1] to create
the device-mapper device, the hash offset address we passed to kernel
module is the hash block number. That means the hash offset address
would have to be aligned to the max(data_block_size, hash_block_size),
otherwise there would be no way to set the correct hash offset address
via "dm-mo.create=".
[1] https://www.kernel.org/doc/Documentation/admin-guide/device-mapper/dm-init.rst
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Fixes warning
```
SyntaxWarning: "is not" with a literal. Did you mean "!="?
```
Signed-off-by: Eero Aaltonen <eero.aaltonen@vaisala.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Add squashfs to images supported by verity.
Signed-off-by: Maciek Borzecki <maciek@thing.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
[PATCH] Add support for the EROFS image, and it's compressed options,
to the dm-verity-img.bbclass setup, theoretically this is a simple addition
to the list of types however there is a quirk in how Poky handles the
filesystems in poky/meta/classes/image_types.bbclass.
Specifically the 'IMAGE_CMD' and 'IMAGE_FSTYPES' use a hyphen, e.g.
erofs-lz4, however in the image_type bbclass the task for that would be
"do_image_erofs_lz4", replacing the hyphen with an underscore.
As the dm-verity-img.bbclass adds a dependency to the wic image creation
on the do_image_* task then it fails as there is no
"do_image_erofs-lz4", so simply replace the hypen with an underscore.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
CONVERSION_DEPENDS hasn't been converted to the new syntax.
Fixes: a23ceef ("dm-verity-img.bbclass: more overided fixups")
Signed-off-by: Kristian Klausen <kristian@klausen.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Add DM_VERITY_IMAGE_DATA_BLOCK_SIZE to be able to set the
--data-block-size used in veritysetup. Tuning this value effects the
performance and size of the resulting image.
Signed-off-by: Christer Fletcher <christer.fletcher@inter.ikea.com>
Signed-off-by: Paulo Neves <paulo.neves1@inter.ikea.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Introduce new STAGING_VERITY_DIR variable specific to this bbclass which
defines the directory where the verity.env file is stored during
<DM_VERITY_IMAGE>:do_image_<DM_VERITY_IMAGE_TYPE> task and can
consequtively be picked up into associated initramfs rootfs (which
facilitates executing 'veritysetup' and related actions).
By doing this we mitigate failures that were thus far associated to this
facility, such as
install: cannot stat '.../build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4.verity.env': No such file or directory
and
install: cannot stat '.../build/tmp/deploy/images/beaglebone-yocto/core-image-minimal-beaglebone-yocto.ext4.verity.env': No such file or directory
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Relocate checking if DM_VERITY_IMAGE and DM_VERITY_IMAGE_TYPE are
defined as non-empty strings before DM_VERITY_IMAGE vs. PN
comparison is performed. By doing so we start seeing following kind
of bitbake parse-time console warnings in case either DM_VERITY_IMAGE
or DM_VERITY_IMAGE_TYPE is not set, when 'dm-verity-img' is defined
in IMAGE_CLASSES:
WARNING: .../meta/recipes-core/images/core-image-minimal.bb: dm-verity-img class inherited but not used
WARNING: .../meta-openembedded/meta-oe/recipes-core/images/meta-oe-ptest-image.bb: dm-verity-img class inherited but not used
whereas before this change this warning was printed only once, when
image pointed by <DM_VERITY_IMAGE> was parsed (and recipe with that
name could be found in BBFILES mask scipe), and DM_VERITY_IMAGE_TYPE
was not set.
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Resort to printf in order to avoid usage of non-POSIX compliant echo
flags. This mitigates following errors visible in console during
boot-up with image that has been built on a host that symlinks
'/bin/sh' to 'dash':
/init: /usr/share/dm-verity.env: line 1: -NE_UUID: not found
/init: /usr/share/dm-verity.env: line 2: -ne: not found
/init: /usr/share/dm-verity.env: line 3: 642864e8-6a17-46b9-ba1e-9386a3909c8d: not found
/init: /usr/share/dm-verity.env: line 4: -NE_HASH_TYPE: not found
/init: /usr/share/dm-verity.env: line 5: -ne: not found
/init: /usr/share/dm-verity.env: line 6: 1: not found
/init: /usr/share/dm-verity.env: line 7: -NE_DATA_BLOCKS: not found
/init: /usr/share/dm-verity.env: line 8: -ne: not found
/init: /usr/share/dm-verity.env: line 9: 12064: not found
/init: /usr/share/dm-verity.env: line 10: -NE_DATA_BLOCK_SIZE: not found
/init: /usr/share/dm-verity.env: line 11: -ne: not found
/init: /usr/share/dm-verity.env: line 12: 1024: not found
/init: /usr/share/dm-verity.env: line 13: -NE_HASH_BLOCK_SIZE: not found
/init: /usr/share/dm-verity.env: line 14: -ne: not found
/init: /usr/share/dm-verity.env: line 15: 4096: not found
/init: /usr/share/dm-verity.env: line 16: -NE_HASH_ALGORITHM: not found
/init: /usr/share/dm-verity.env: line 17: -ne: not found
/init: /usr/share/dm-verity.env: line 18: sha256: not found
/init: /usr/share/dm-verity.env: line 19: -NE_SALT: not found
/init: /usr/share/dm-verity.env: line 20: -ne: not found
/init: /usr/share/dm-verity.env: line 21: 19d98185b42a897a37db6c56c7470ab2d455f0de46daa0df735eee6263816439: not found
/init: /usr/share/dm-verity.env: line 22: -NE_ROOT_HASH: not found
/init: /usr/share/dm-verity.env: line 23: -ne: not found
/init: /usr/share/dm-verity.env: line 24: 298d75fc2ea27fe594b6a37158a6ae7538e77d918bab98c475934f625de0e4ab: not found
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
This adds a class that allows to generate conversions of ext[234] and
btrfs partitions images with dm-verity hash data appended at the end as
well as a corresponding .env file containing the root hash and data
offset that can be stored in a secure location (e.g. signed fitImage)
or signed and verified at run-time on its own.
The class depends on two variables:
DM_VERITY_IMAGE: defines the name of the main image (normally the
one that is used with the bitbake command to
build the main image)
DM_VERITY_IMAGE_TYPE: defines exactly one type for which to generate
the protected image.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
Kevin Hao
Mikko Rapeli
Erik Schilling
Paul Gortmaker
Eero Aaltonen
Maciej Borzęcki
Josh Harley
Kristian Klausen
Christer Fletcher
Armin Kuster
niko.mauno@vaisala.com
Bartosz Golaszewski