summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPaul Gortmaker <paul.gortmaker@windriver.com>2023-06-21 10:13:33 -0700
committerArmin Kuster <akuster808@gmail.com>2023-06-25 15:05:28 -0400
commit3b88f75323bd399615eb6c0897b13cbb59e35e64 (patch)
treef50d025393bc0191e55e941b55a07ddcff9210d6
parent4922b3053af9e0f66a3e0a65bd25b9f51df3a4f9 (diff)
downloadmeta-security-3b88f75323bd399615eb6c0897b13cbb59e35e64.tar.gz
dm-verity: add wks.in fragment with dynamic build hash data
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 <paul.gortmaker@windriver.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
-rw-r--r--classes/dm-verity-img.bbclass23
1 files changed, 23 insertions, 0 deletions
diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index 8351ab2..045c860 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -18,6 +18,13 @@
18# DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs 18# DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
19# DM_VERITY_SEPARATE_HASH = "1" # optional; store hash on separate dev 19# DM_VERITY_SEPARATE_HASH = "1" # optional; store hash on separate dev
20# IMAGE_CLASSES += "dm-verity-img" 20# IMAGE_CLASSES += "dm-verity-img"
21#
22# Using the GPT UUIDs specified in the standard can also be useful in that
23# they are displayed and translated in cfdisk output.
24#
25# DM_VERITY_ROOT_GUID = <UUID for your architecture and root-fs>
26# DM_VERITY_RHASH_GUID = <UUID for your architecture and verity-hash>
27# https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
21 28
22# The resulting image can then be used to implement the device mapper block 29# The resulting image can then be used to implement the device mapper block
23# integrity checking on the target device. 30# integrity checking on the target device.
@@ -35,12 +42,20 @@ DM_VERITY_IMAGE_HASH_BLOCK_SIZE ?= "4096"
35# Should we store the hash data on a separate device/partition? 42# Should we store the hash data on a separate device/partition?
36DM_VERITY_SEPARATE_HASH ?= "0" 43DM_VERITY_SEPARATE_HASH ?= "0"
37 44
45# These are arch specific. We could probably intelligently auto-assign these?
46# Take x86-64 values as defaults. No impact on functionality currently.
47# See SD_GPT_ROOT_X86_64 and SD_GPT_ROOT_X86_64_VERITY in the spec.
48# Note - these are passed directly to sgdisk so hyphens needed.
49DM_VERITY_ROOT_GUID ?= "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
50DM_VERITY_RHASH_GUID ?= "2c7357ed-ebd2-46d9-aec1-23d437ec2bf5"
51
38# Process the output from veritysetup and generate the corresponding .env 52# Process the output from veritysetup and generate the corresponding .env
39# file. The output from veritysetup is not very machine-friendly so we need to 53# file. The output from veritysetup is not very machine-friendly so we need to
40# convert it to some better format. Let's drop the first line (doesn't contain 54# convert it to some better format. Let's drop the first line (doesn't contain
41# any useful info) and feed the rest to a script. 55# any useful info) and feed the rest to a script.
42process_verity() { 56process_verity() {
43 local ENV="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.verity.env" 57 local ENV="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.verity.env"
58 local WKS_INC="${STAGING_VERITY_DIR}/${IMAGE_BASENAME}.$TYPE.wks.in"
44 rm -f $ENV 59 rm -f $ENV
45 60
46 # Each line contains a key and a value string delimited by ':'. Read the 61 # Each line contains a key and a value string delimited by ':'. Read the
@@ -86,6 +101,14 @@ process_verity() {
86 # Emit the values needed for a veritysetup run in the initramfs 101 # Emit the values needed for a veritysetup run in the initramfs
87 echo "ROOT_UUID=$ROOT_UUID" >> $ENV 102 echo "ROOT_UUID=$ROOT_UUID" >> $ENV
88 echo "RHASH_UUID=$RHASH_UUID" >> $ENV 103 echo "RHASH_UUID=$RHASH_UUID" >> $ENV
104
105 # Create wks.in fragment with build specific UUIDs for partitions.
106 # Unfortunately the wks.in does not support line continuations...
107 # First, the unappended filesystem data partition.
108 echo 'part / --source rawcopy --ondisk sda --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity" --part-name verityroot --part-type="${DM_VERITY_ROOT_GUID}"'" --uuid=\"$ROOT_UUID\"" > $WKS_INC
109
110 # note: no default mount point for hash data partition
111 echo 'part --source rawcopy --ondisk sda --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.vhash" --part-name verityhash --part-type="${DM_VERITY_RHASH_GUID}"'" --uuid=\"$RHASH_UUID\"" >> $WKS_INC
89} 112}
90 113
91verity_setup() { 114verity_setup() {