The primary goal here is to enable storage of dm-verity hash on a separate device/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. I originally also was looking at the systemd "autoconfiguration" that only needs the root hash on the boot line in order to autodetect the partitions with the filesystem data and with the hash data. However, that became a bridge too far once I realized that using systemd instead of a simple /init script in the initramfs was an unavoidable hard dependency. While that is apparently a thing, I couldn't find anyone doing it by default, even in the desktop distro space. That said, there are good ideas in how the autodetection is supported. Like using partition UUIDs based on the root hash. Setting proper GPT types that reflect it is verity-root or verity-hash; setting sensible GPT names, etc. So in addition to supporting a separate hash using our current script based initramfs /init -- everything done here is done in a systemd autodetect compatible way. Meaning that if someone eventually tackles supporting a systemd based /init in the initramfs, we'll have the separate hash and a worked example that sets everything up in a compatible fashion for that. A side benefit of doing that, is that if you run cfdisk (or similar) on your output device after writing the wic image to it, you get useful info on the decoding of the GPT types, see the GPT names, etc. Testing: I boot tested the new separate hash support on both an older i7 desktop, and a slightly newer atom based netbook - using wic and a USB drive with the included documented steps. Since I'm touching files for our existing appended hash, I also went back and tested that on the same two machines. Final note - astute reviewers may note a hard coded path to "bc" -- this is done because even though we have "tr" at that phase of the build, we don't have "bc" because it is a separate stand-alone package. I've got general agreement on IRC that adding our sysroot "bc" to that phase of the build makes sense. So once I've done that in oe, I'll circle back here and strip off the paths - avoiding timing dependencies between oe and meta-security. Paul Gortmaker (7): dm-verity: add descriptive strings for "wic list images" dm-verity: restructure the veritysetup arg parsing dm-verity: save veritysetup args beside runtime environment dm-verity: add support for hash storage on separate partition dm-verity: add wks.in fragment with dynamic build hash data dm-verity: hook separate hash into initramfs framework dm-verity: add sample systemd separate hash example and doc classes/dm-verity-img.bbclass | 94 ++++++++++++++++++- docs/dm-verity-systemd-hash-x86-64.txt | 43 +++++++++ .../initramfs-framework-dm/dmverity | 29 ++++++ wic/beaglebone-yocto-verity.wks.in | 1 + wic/systemd-bootdisk-dmverity-hash.wks.in | 18 ++++ wic/systemd-bootdisk-dmverity.wks.in | 1 + 6 files changed, 184 insertions(+), 2 deletions(-) create mode 100644 docs/dm-verity-systemd-hash-x86-64.txt create mode 100644 wic/systemd-bootdisk-dmverity-hash.wks.in -- 2.39.0
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60380): https://lists.yoctoproject.org/g/yocto/message/60380 Mute This Topic: https://lists.yoctoproject.org/mt/99681421/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-