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

[Tobias Waldekranz <tobias@waldekranz.com>]

On tor, okt 09, 2025 at 08:37, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> Hi,
>
> On 10/8/25 10:57 PM, Tobias Waldekranz wrote:
>> On ons, okt 08, 2025 at 09:30, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>> - ...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.
>> 
>> So would you like those patches to add a clone+configure+build of
>> genimage to the Containerfile, or what do you have in mind?
>> 
>> The other option would be to make do without genimage, and create the
>> DDI using veritysetup+openssl(1)+dd.
>> 
>> Which would you prefer?
>
> First one sounds good to me.

Ack.

>> 
>>>> 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.
>> 
>> Yes, this is the approach I have taken:
>> https://github.com/wkz/barebox/commit/f2ee4cb4670c32104ac2ef2791c9e525b0d323ff
>
> Sounds good. Should we just skip MD5/SHA1 for new features though?

That is fine by me. I just went for the full gamut. Ultimately, it is a
build-time option that specifies which subset of fingerprints to
collect. On my branch, only SHA256 can be chosen, since that is what DPS
uses, but if any other feature needs something else, then it can easily
be added:

https://github.com/wkz/barebox/commit/58eb40aa5370ca2b35b0f949f0bd605e8eba9a10

>>> I might take you up on that if you are at 39c3 or FrOSCon ;)
>> 
>> Unfortunately not - hopefully our paths will cross at some other
>> conference! :)
>
> :)
>
>>> 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.
>> 
>> If you want (a) backwards compatibility and (b) something that does not
>> require any ACK from the UAPI group, then I think it is the best we can
>> do.
>
> Ack.
>
>>> 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)
>> 
>> Cool. Can you then place a unique ID from a fusebox or something in the
>> token, so that it is bound to a single device?
>
> Yes, the i.MX8M SoC unique ID was used as claim to bind the JWT to a
> specific HW. In the meantime, Marco imported SoC framework support from
> Linux, so we have a unified API for the unique ID that could be used.

Perfect!

> Cheers,
> Ahmad
>
>> 
>>> 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 |
>> 
>
> -- 
> 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 |