linux/meta-security.git/classes, branch scarthgap

dm-verity: Set the IMAGE_FSTYPES correctly when dm-verity is enabled

2024-03-27T16:36:58+00:00

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 Signed-off-by: Armin Kuster

dm-verity: Adjust the image names according to the oe-core change

2024-03-27T16:36:58+00:00

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 Signed-off-by: Armin Kuster

dm-verity-img.bbclass: add DM_VERITY_DEPLOY_DIR

2023-12-29T14:09:30+00:00

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 Reviewed-by: Erik Schilling Signed-off-by: Armin Kuster

dm-verity-img.bbclass: remove IMAGE_NAME_SUFFIX

2023-12-29T14:09:30+00:00

It is embedded into IMAGE_NAME since poky master branch commit 6f6c79029bc2020907295858449c725952d560a1 Signed-off-by: Mikko Rapeli Signed-off-by: Erik Schilling Signed-off-by: Armin Kuster

dm-verity-img.bbclass: use bc-native

2023-12-29T14:09:30+00:00

Build host may not have bc. Signed-off-by: Mikko Rapeli Signed-off-by: Erik Schilling Signed-off-by: Armin Kuster

dm-verity: add wks.in fragment with dynamic build hash data

2023-06-25T19:05:28+00:00

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 Signed-off-by: Armin Kuster

dm-verity: add support for hash storage on separate partition

2023-06-25T19:05:28+00:00

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 Signed-off-by: Armin Kuster

dm-verity: save veritysetup args beside runtime environment

2023-06-25T19:05:28+00:00

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 Signed-off-by: Armin Kuster

dm-verity: restructure the veritysetup arg parsing

2023-06-25T19:05:28+00:00

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 Signed-off-by: Armin Kuster

dm-verity-img.bbclass: Fix the hash offset alignment issue

2023-03-20T20:27:24+00:00

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 Signed-off-by: Armin Kuster