diff options
author | Paul Gortmaker <paul.gortmaker@windriver.com> | 2023-06-21 10:13:32 -0700 |
---|---|---|
committer | Armin Kuster <akuster808@gmail.com> | 2023-06-25 15:05:28 -0400 |
commit | 4922b3053af9e0f66a3e0a65bd25b9f51df3a4f9 (patch) | |
tree | 99d349f20894e1799749d3da0333fe5d7f8be791 /dynamic-layers/meta-perl/recipes-security/bastille/files/upgrade_options_processing.patch | |
parent | 39c69c8b5dd56730c469c90e934f8b0606331d3b (diff) | |
download | meta-security-4922b3053af9e0f66a3e0a65bd25b9f51df3a4f9.tar.gz |
dm-verity: add support for hash storage on separate partition
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>
Diffstat (limited to 'dynamic-layers/meta-perl/recipes-security/bastille/files/upgrade_options_processing.patch')
0 files changed, 0 insertions, 0 deletions