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>
[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>
Fix the variable spelling errors
s/SKIP_META_SECUIRTY_SANITY_CHECK/SKIP_META_SECURITY_SANITY_CHECK
Signed-off-by: George Liu <liuxiwei@inspur.com>
Acked-by: Martin Jansa <Martin.Jansa@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>
Inheriting the class will cause the check_security function to run on the
ROOTFS image. Currently the check_security function just invokes
buck-security-native on the root filesystem of the image.
