[PATCH 00/11] dm: verity: Add transparent integrity checking target
Ahmad Fatoum
a.fatoum at pengutronix.de
Wed Oct 8 23:37:33 PDT 2025
Hi,
On 10/8/25 10:57 PM, Tobias Waldekranz wrote:
> On ons, okt 08, 2025 at 09:30, Ahmad Fatoum <a.fatoum at 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.
>
>>> 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?
>> 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.
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 at 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 at rv64i_defconfig.yaml | 1 +
>>>>> test/riscv/qemu at 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 |
More information about the barebox
mailing list