[meta-security,0/7] dm-verity: separate device for hash storage

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