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

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

Hi,

On 07.10.25 22:15, Tobias Waldekranz wrote:
> On tis, okt 07, 2025 at 11:05, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>> 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.
> 
> IMO, for this particular feature, it is certainly possible to get by
> without something like that. I have implemented signature validation by
> pretty much following the road-map detailed in my original message:
> 
> https://github.com/wkz/barebox/commit/4779bd7c766bab704aed982d8fa79d99078633b7#diff-4a7f94e9bbcea0d43614b6f3e7edeedfc0a597a1d284c9ffe4f002ad621f580fR127-R128

Cool. mbedtls will have to wait then...

/me dreams of a future with a network block device on top of a smoltcp
stack that maps a verity RAUC bundle that's downloaded as needed via
HTTP range requests and then network booted (after verifying the
signed root hash with mbedtls of course). Not because we absolutely need
to, but because we can.

> The work is now stalled on getting
> https://github.com/pengutronix/genimage/pull/312 merged (yes, I am
> shamelessly trying to get some attention on this PR :)),

This might turn out to be successful. Let's see..

> 
> - ...so that can be included in a new release of genimage,
> 
> - ...so that I can eventually include that in
>   ghcr.io/barebox/barebox/barebox-ci,

I have little issue with building our own genimage during container
creation or even our own Qemu (just thought about it today because of
https://patchwork.ozlabs.org/project/qemu-devel/list/?series=472897&state=*

> - ...so that I can then use it to generate test images,
> 
> - ...so that I can write tests,
> 
> - ...so that I can publish v1
> 
> ...its...a whole thing :)

IMO, just send patches against the Containerfile and we rebuild it.
We can create a new subdirectory, move the Containerfile into it and
put the patches there as well.

> Anyway, this only works with existing crypto primitives because (a) we
> can use the certificateFingerprint property to locate the key, without
> having to parse the PKCS#7 data and (b) because the hash algorithm is
> specified by DPS to SHA256, again letting us skip over parsing the ASN.1
> data to determine that.
> 
> If we want to support more general operations, e.g. have some
> lightweight openssl(1)-like command that can validate detached
> signatures, then I think something like mbedtls is definitely needed.

I see.

>> 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"
> 
> Shiny! Being able to have multiple keyrings is a great feature.

Yes, and it would be extensible to associate extra data with a key
in case you need this, although your fingerprint should probably
just be generated by keytoc.

>> This makes sense, even if there is no decision yet for
>> https://github.com/uapi-group/specifications/issues/167
> 
> Ehm, yeah. I have lots of thoughts about the response to this
> issue. Maybe over a beer sometime :)

I might take you up on that if you are at 39c3 or FrOSCon ;)

>> I would suggest we hardcode (and document) that in case there are
>> multiple candidates, the ones closest after the root partition are taken?
> 
> I think this is a great approach. Simple, yet seems like it solves all
> the common setups.

It's a bit magic/implicit, but if we are going to implement it as is some
way, this would make it at least reproducible.

>>> - 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.
> 
> No no, forget that - just I suggested that someone who already owns a
> 2kW electric nailgun should buy a hammer :)

Heh, I think there is place for both. If something is not needed at all
in a build, we should still be able to disable it completely with no
way back (sans exploits).

> I just watched your talk and Security policies sound really great!
> 
> Is there any information/examples on how to use JWTs to dynamically
> switch into a developer/rma mode?

The project for which I upstreamed JWT support hasn't yet switched
over to security policies (v2025.10.0 will be the first release with them
expectedly). I will probably add an example to the 32-bit Qemu platform,
so it's possible to:

pytest --interactive --bootarg barebox.security.token=$(cat common/boards/qemu-virt/devel.token)

Cheers,
Ahmad

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


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