On 9/25/24 11:28 PM, Luca Boccassi wrote:
Do people use veritysetup (libcryptsetup) here, or does it run with its separate userspace tooling?
This is used with libcryptsetup commonly, and often with veritysetup.
It is fairly easy to test in a VM or on baremetal, it is not required
to build your own kernel - that's the reason for supporting
secondary+platform keyrings (the first one allows you to enroll keys
in MOK, the second one for UEFI DB).
We would even have a CI testing this for every PR and merge in systemd
on Github, _except_ there is currently an issue (unrelated to
dmverity) that happens when nesting KVM with UEFI secure boot enabled
on top of HyperV, which means it cannot be used reliably on Github
Actions. Once that is solved, this will be again part of the systemd
CI integration tests. But it is used regularly by developers on their
machines.
Hi Luca,
good to know that libcryptswtup userspace is then used here, thanks for the info!
I have some more questions, but that is not related to this thread,
I will ask in another mail later.
Thanks,
Milan
It might not be commonly used by kernel developers, I do not know as I
am not a kernel developer, but it is becoming more and more common in
userspace and among image builders. For example the mkosi image
builder, using systemd-repart, can very easily build distro images
using signed dm verity. I am at All Systems Go and just today there
were multiple talks by multiple people using dmverity images for their
distros/platforms/products, especially with systemd-sysext, which is
all about signed dm-verity.
In 6.12 we will also have IPE which allows to enable trusted code
integrity checks that cannot be trivially bypassed by other userspace
processes running with root or caps. This has been, still is and will
be for the foreseeable future, in use in the Azure infrastructure.
Hope this provides some clarity, let me know if you need more info.
