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

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

Hi,

On 18.09.25 09:43, 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.
> 
> TL;DR: What follows is just a discussion about the future - it has
>        nothing to do with the contents of this series.

Thanks for pointing out the shed for I come with color.

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

We've been piecewise importing crypto primitives from the Linux kernel
so far, but I've been thinking if we shouldn't take the leap and import
mbedtls, but we haven't had the need so far. Sascha is not opposed, if
there's a good use case for it.

> 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.
> 
>    We could also support parsing fingerprints from a DT. Not sure if
>    this is needed.

ECDSA support in barebox afaik doesn't have a DT representation and
going forward CONFIG_CRYPTO_PUBLIC_KEYS is the standard way to pass keys
into barebox.

Jonas (Cc'd) is working right now in a backwards-compatible manner of
attaching meta-data to keys, e.g.:

export myfitkey="keyring=fit,hint=myhint:pkcs11:token=foo,bar;object=bl"
export myjwtkey="keyring=jwt-myboard:jwt_pub.pem"


scripts/config --set-str CONFIG_CRYPTO_PUBLIC_KEYS \
		"__ENV_myfitkey __ENV_myjwtkey"

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

This makes sense, even if there is no decision yet for
https://github.com/uapi-group/specifications/issues/167

I would suggest we hardcode (and document) that in case there are
multiple candidates, the ones closest after the root partition are taken?

> 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.
> 
> - Having the ability to tag a partition as trusted, which could then
>   be used to tag filesystems as such.

This would mesh nicely with security policies. We can allow board code
to tag device files and then mounting them would be allowed even if
SCONFIG_FS_UNTRUSTED is disabled per currently active security policy.

> - Having a build-time option that limits booting to only be allowed
>   from trusted filesystems.

Ye, for users without security policies, a build-time option would be apt.

Cheers,
Ahmad

> 
> Tobias Waldekranz (11):
>   dm: Add helper to manage a lower device
>   dm: linear: Refactor to make use of the generalized cdev management
>   dm: verity: Add transparent integrity checking target
>   dm: verity: Add helper to parse superblock information
>   commands: veritysetup: Create dm-verity devices
>   ci: pytest: Open up testfs to more consumers than the FIT test
>   ci: pytest: Enable testfs feature on malta boards
>   ci: pytest: Generate test data for dm-verity
>   test: pytest: add basic dm-verity test
>   ci: pytest: Centralize feature discovery to a separate step
>   ci: pytest: Enable device-mapper labgrid tests
> 
>  .github/workflows/test-labgrid-pytest.yml     |  26 +-
>  arch/mips/configs/qemu-malta_defconfig        |   4 +
>  commands/Kconfig                              |  10 +
>  commands/Makefile                             |   1 +
>  commands/veritysetup.c                        | 123 +++++
>  .../boards/configs/enable_dm_testing.config   |   9 +
>  drivers/block/dm/Kconfig                      |   7 +
>  drivers/block/dm/Makefile                     |   1 +
>  drivers/block/dm/dm-core.c                    | 118 ++++
>  drivers/block/dm/dm-linear.c                  |  64 +--
>  drivers/block/dm/dm-target.h                  |  34 ++
>  drivers/block/dm/dm-verity.c                  | 517 ++++++++++++++++++
>  include/device-mapper.h                       |   5 +
>  scripts/generate_testfs.sh                    |  64 ++-
>  test/mips/be@qemu-malta_defconfig.yaml        |   1 +
>  test/mips/qemu-malta64el_defconfig.yaml       |   1 +
>  test/py/test_dm.py                            |  38 ++
>  test/py/test_fit.py                           |   4 +-
>  test/riscv/qemu-virt64@rv64i_defconfig.yaml   |   1 +
>  test/riscv/qemu@virt32_defconfig.yaml         |   1 +
>  20 files changed, 968 insertions(+), 61 deletions(-)
>  create mode 100644 commands/veritysetup.c
>  create mode 100644 common/boards/configs/enable_dm_testing.config
>  create mode 100644 drivers/block/dm/dm-verity.c
>  create mode 100644 test/py/test_dm.py
> 


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