Verity: add support for root hash signature #16249
Conversation
|
I have not pushed a commit with an update for the veritysetup-generator as I'm struggling a bit to get an image to test it - given Debian doesn't use dracut/systemd in the initramfs it's a bit difficult to produce one. The veritysetup binary can be used standalone though, and it works fine, so shouldn't be a blocker. |
|
Note that I didn't exercise this functionality in TEST-50-DISSECT because, due to the variability of the test image, I don't know of a reliable way to check whether the kernel + cryptsetup provide the functionality. If anybody has any suggestion, I'm happy to work on that. |
|
Hmm, I thought Debian also shipped dracut? Maybe you can make things work with that? |
bluca
force-pushed
the
root_verity_sig
branch
2 times, most recently
from
6409feb to
0747596
Compare
poettering
added
the
good-to-merge/waiting-for-ci 👍
|
LGTM's status is failed here, but on its website is passing? Not sure what's happening: |
|
CI's quite unhappy today: CentOS CI (Arch in KVM) has a failed networkd test, seems unrelated: CentOS CI (CentOS 7) has a failure in the dissect test which, although it tests a changed binary, fails before that, when creating a squashfs in the tmpfs: So it would seem unrelated? @mrc0mmand have you seen these before? |
The networkd fail is #16105, rescheduled. However, I've never seen the dissect one before. |
I see, thank you - it's very weird, it looks like mksquashfs fails to write to a subdir of /tmp |
I'll reschedule the CentOS 7 build as well, to see if it's indeed a flake, but I'll note it in systemd/systemd-centos-ci#251 in case it comes back, so we can possibly debug it further. Edit: I also rescheduled the LGTM run, even though it passed, just to have everything green. The new result should propagate once the run finishes (hopefully). |
Thanks! |
|
bionic-i386 seems to timeout when installing the packages to start the "upstream" test suite |
|
hmm, needs rebase |
Since cryptsetup 2.3.0 a new API to verify dm-verity volumes by a pkcs7 signature, with the public key in the kernel keyring, is available. Use it if libcryptsetup supports it in the veritysetup helper binary.
Since cryptsetup 2.3.0 a new API to verify dm-verity volumes by a pkcs7 signature, with the public key in the kernel keyring, is available. Use it if libcryptsetup supports it.
Allow to explicitly pass root hash signature as a unit option. Takes precedence over implicit checks.
rebased |
|
@poettering would it be useful to think of a way to add support for signatures for the GPT images/discoverable partitions case? I don't plan to use it myself, but the story feels a bit incomplete otherwise |
|
@bluca hmm, maybe. I mean we could define a partition type where one could place the signatures in, so that when dissecting such a disk image we could search for the signature and just use it. But most likely, in that case there should also be the root hash embedded into it. As I understand pkcs#7 actually optionally can contain both the signed data and the signature for it. So if we go that route we probably store a pkcs#7 signed root hash in the new partition table: whenever one of those is found everything else can be derived from it automatically... But anyway, let's just wait until people show up who actually want something like that. Would be kinda cool though, i.e. a fully self-contained signed OS image to boot from. |
|
Actually for some of my use cases (not all of them) I might be able to gently push toward the GPT model, so I might come back to this myself at some point. A new partition was the same thinking I had - I didn't consider the pkcs7 data+sig approach, I'll keep that in mind if I do get back to this. |
3 participants
With kernel 5.4 and libcryptsetup 2.3.0, the verity root hash can be signed by a key in the kernel trusted keyring. Add support for this feature throughout the various components.