meta-security/docs/dm-verity-systemd-hash-x86-64.txt - openbmc/openbmc - Gitiles

 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.
	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.