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

[Sascha Hauer <s.hauer@pengutronix.de>]

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.

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:

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.

> 
> 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.

> 
>    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"

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

> 
> - 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.

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 |