[PATCH 00/11] dm: verity: Add transparent integrity checking target

[Tobias Waldekranz]

On tor, sep 18, 2025 at 16:08, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> Hi Tobias,
>
> On Thu, Sep 18, 2025 at 09:43:10AM +0200, Tobias Waldekranz wrote:
>> This series adds initial support for dm-verity. Notably, it does not
>> include any support for validation of any root hash signature. As
>> such, practical use in a production setting is still limited, unless
>> you have some other way of securely determining that the root hash is
>> valid.
>> 
>> 3/11 is where the action is.
>
> I gave this series a try and it indeed works like a charm. Great :)
>
> I used a verity rootfs I had lying around which has data and hash tree
> on the same partition, but even that worked out of the box.

Glad to hear it! :)

> I did some performance measurements just to get an idea how much penalty
> we have to pay for dm-verity. Here are the times to read a 1 MiB file
> from ext4, from ext4 on dm-verity and from a raw device:

Awesome, thanks for looking into this.

> raw device read:         24.28 ms
> dm-verity raw read:	 33.90 ms
> ext4 on raw device:      24.55 ms
> ext4 on dm-verity:       34.93 ms
> sha256 of 1 MiB:          3.30 ms
>
> (done on eMMC on a TI-AM62L EVM board)
>
> Ideally the difference between raw read and dm-verity read should be
> roughly the time we need for hashing, so it seems there's still some
> performance to squeeze out. Nothing to worry about now, I was just
> curious.

Do you have any sense of the time difference between a single digest of
1M compared to 256 4k (the default data block size) digests? I assume
you pay some penalty, but I have no idea if it could explain this
difference.

On that note, one thing that I think can be optimized, though I have no
profiling data to back this up yet, is how the digest object is
reused. Here is the relevant part:

static int dm_verity_set_digest(struct dm_verity *v, const void *buf, size_t buflen)
{
	int err;

	err = digest_init(v->digest_algo);
	err = err ? : digest_update(v->digest_algo, v->salt, v->salt_size);
	err = err ? : digest_update(v->digest_algo, buf, buflen);
	err = err ? : digest_final(v->digest_algo, v->verify.digest);
	return err;
}

Since the salt is fixed, the state of digest_algo after
init()+update(salt) is also fixed. So if there was a way to capture and
restore the digest to this known state, we could replace
init()+update(salt) with a memcpy(). There was no such API that I could
find (which makes sense, this is not the normal use-case), so I took the
naive approach. But maybe the performance gains would warrant something
a bit more quirky.

What was that saying about premature optimization again? :)

>> 
>> TL;DR: What follows is just a discussion about the future - it has
>>        nothing to do with the contents of this series.
>> 
>> 
>> Once this is in place, signature validation is next on my TODO. The
>> kernel accepts a PKCS7 signature for this purpose. This is therefore
>> also what Discoverable Partitions Specification (DPS) provides in its
>> <arch>-<part>-verity-sig partitions, which contain a NUL-padded JSON
>> document like this:
>> 
>> {
>> 	"roothash": "0123456789abcdef...",
>> 	"certificateFingerprint": "0123456789abcdef..",
>> 	"signature": "MIIINQYJKo..."
>> }
>> 
>> To avoid having to integrate full ASN.1 + X509 parsing in Barebox, my
>> plan is:
>> 
>> 1. Add support for (optionally) storing a certificate fingerprint
>>    along with a `struct public_key`. So at build time, we can note the
>>    fingerprint of keys that we include in the builtin keystore.
>
> Something like
> https://lore.barebox.org/barebox/20250821-keynames-v1-3-8144af76d0ab@pengutronix.de/
> ?
>
> I don't know if that fingerprint is in the format you need it though.

Unfortunatly not. The fingerprint produced by systemd-repart (which is
the reference implementation for creating DPS images, AFAIK) is of the
entire X509 cert, e.g.:

  barebox$ openssl x509 -fingerprint -sha256 -in crypto/fit-ecdsa-development.crt -noout
  sha256 Fingerprint=BA:50:D7:38:EA:68:AE:78:07:DD:C4:2E:5D:D6:26:69:B3:3E:0A:85:7D:BE:B0:98:9B:A5:F5:69:7D:A2:F6:A0

I have started to sketch this out:

https://github.com/wkz/barebox/tree/dm-verity-sig

>> 
>>    We could also support parsing fingerprints from a DT. Not sure if
>>    this is needed.
>> 
>> 2. Add a simplified PKCS7 validation function that relies on:
>>    a. Knowing which public key to use in advance, rather than
>>       determining it by walking the ASN.1 data.
>>    b. The last $KEY_LEN_BYTES of the PKCS7 blob holds the raw
>>       RFC4880§5.2.2 signature bytes that Barebox already knows how to
>>       verify.
>> 
>> 3. Add a "dps-open" subcommand to veritysetup that only requires the
>>    partition to open and a name for the dm-verity device:
>> 
>>    veritysetup dps-open /dev/disk0.root os
>> 
>>    Based on the partition type UUID, we would then locate the
>>    corresponding -verity and -verity-sig partitions, parse the verity
>>    superblock, validate the signature and then create the dm-verity
>>    device.
>> 
>> Some other thoughts for the future (I have done no research here, so
>> some of this might already exist in Barebox and I just haven't
>> stumbled across it):
>> 
>> - Similar to the automounter, it would be good to have an
>>   "auto-dps-verityer" that will do the equivalent of `veritysetup
>>   dps-open` on the DPS partitions matching the current architecture.
>
> Once you have the dps-open subcommand you might be able to use the
> autmount mechanism as-is. Something like:
>
> autmount -d /mnt/mmc0.os "veritysetup dps-open /dev/disk0.root os && mount /dev/os /mnt/mmc0.os"

Interesting, I have to read up on this.

> Maybe we can automatically create these automountpoints once we find
> suitable GUIDs on a device.

I think something like that would be ideal. Then Barebox should more or
less be able to automatically produce a list of all trusted boot sources
(using the existing blspec logic (which I also know too little about :))

>> 
>> - Having the ability to tag a partition as trusted, which could then
>>   be used to tag filesystems as such.
>> 
>> - Having a build-time option that limits booting to only be allowed
>>   from trusted filesystems.
>
> Yes, there's still some work to do in this area. Right now our secure
> boot approach only allows signed FIT images. Now with dm-verity not the
> Kernel image itself becomes trusted, but the underlying filesystem. We
> are not really prepared for that.

Right, that is fully understandable.

> Sascha
>
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |