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

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

dm-verity-img.bbclass: fix syntax warning

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

Fixes warning ``` SyntaxWarning: "is not" with a literal. Did you mean "!="? ``` Signed-off-by: Eero Aaltonen Signed-off-by: Armin Kuster

dm-verity-img.bbclass: add squashfs images

2023-02-11T15:36:23+00:00

Add squashfs to images supported by verity. Signed-off-by: Maciek Borzecki Signed-off-by: Armin Kuster

classes: add aide routines

2022-06-24T01:47:59+00:00

Signed-off-by: Armin Kuster

Add EROFS support to dm-verity-img class

2022-05-01T17:26:52+00:00

[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

dm-verity-img.bbclass: Fix wrong override syntax for CONVERSION_DEPENDS

2021-12-25T19:31:45+00:00

CONVERSION_DEPENDS hasn't been converted to the new syntax. Fixes: a23ceef ("dm-verity-img.bbclass: more overided fixups") Signed-off-by: Kristian Klausen Signed-off-by: Armin Kuster