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

dm-verity-img.bbclass: set sparse as "never" during initial file copy

2025-03-12T19:31:15+00:00

This is needed when a verity image is used in conjunction with tools like a WIC and a bmap file, as avoiding writing "sparse" sectors can result in errors in the signature verification. Signed-off-by: Lorenzo Arena Signed-off-by: Armin Kuster

dm-verity: set staging correctly in case basename has changed

2024-12-16T17:49:13+00:00

Fix the verity class when the IMAGE_BASENAME has changed. Prefer DM_VERITY_IMAGE for staging env and wic fragment so it matchs what is used in the dm-verity-image-initramfs and the base wks systemd-bootdisk-dmverity.wks.in. Signed-off-by: Louis Rannou Signed-off-by: Louis Rannou Signed-off-by: Armin Kuster

dm-verity-img.bbclass: add DM_VERITY_SETUP_ARGS

2024-12-16T17:49:04+00:00

Useful to pass additional arguments to veritysetup, for example '--no-superblock' to make system less vulnerable to certain types of attacks and data maniputaion on the disk. Signed-off-by: Grygorii Tertychnyi Signed-off-by: Armin Kuster

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