diff options
Diffstat (limited to 'docs/dm-verity-systemd-hash-x86-64.txt')
-rw-r--r-- | docs/dm-verity-systemd-hash-x86-64.txt | 43 |
1 files changed, 43 insertions, 0 deletions
diff --git a/docs/dm-verity-systemd-hash-x86-64.txt b/docs/dm-verity-systemd-hash-x86-64.txt new file mode 100644 index 0000000..673b810 --- /dev/null +++ b/docs/dm-verity-systemd-hash-x86-64.txt @@ -0,0 +1,43 @@ +dm-verity and x86-64 and systemd - separate hash device +------------------------------------------------------- + +Everything said in "dm-verity-systemd-x86-64.txt" applies here. +However booting under QEMU is not tested - only on real hardware. +So for your MACHINE you need to choose "genericx86-64". + +Also, you'll need to point at the hash specific WKS file: + +WKS_FILES += " systemd-bootdisk-dmverity-hash.wks.in" + +The fundamental difference is to use a separate device/partition for +storage of the hash data -- instead of "hiding" it beyond the filesystem +in what is essentially a 5-10% oversized partition. This takes any manual +math calculations of size/offset out of the picture, and uses the kernel's +natural behaviour of compartmentalizing devices to ensure they are separate. + +The example hash.wks file added here essentially adds a hash-only partition +directly after the filesystem partition. So the filesystem partition is +no longer "oversized" and no offsets are needed/used. + +Since we are now using multiple partitions, we make a better effort to use +accepted GPT partition types and UUIDs based on the roothash. This means +easier sysadmin level use/debugging based on cfdisk output etc. + +Generating the separate root hash image is driven off enabling this: + DM_VERITY_SEPARATE_HASH = "1" + +Two other variables control the GPT UUIDs - set to x86-64 defaults: + + DM_VERITY_ROOT_GUID ?= "4f68bce3-e8cd-4db1-96e7-fbcaf984b709" + DM_VERITY_RHASH_GUID ?= "2c7357ed-ebd2-46d9-aec1-23d437ec2bf5" + +See: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ + +Finally, the UUIDs (not the "partition types" above) are based off of +the root node hash value as per the systemd "autodetect" proposed standard. +These will obviously change with every update/rebuild of the root image. + +While not strictly coupled to any functionality at this point in time, it +does aid in easier debugging, and puts us in alignment with using systemd +inside the initramfs to replace manual veritysetup like configuration we +currently do in the initramfs today, should we decide to do so later on. |