From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Tobias Waldekranz <tobias@waldekranz.com>,
barebox@lists.infradead.org,
Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jonas Rebmann <jre@pengutronix.de>
Subject: Re: [PATCH 00/11] dm: verity: Add transparent integrity checking target
Date: Thu, 9 Oct 2025 08:37:33 +0200 [thread overview]
Message-ID: <24151bf4-46bb-466b-a2c8-b8324e4b9b9b@pengutronix.de> (raw)
In-Reply-To: <875xcp1599.fsf@waldekranz.com>
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.
>
>>> 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@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 |
next prev parent reply other threads:[~2025-10-09 6:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 7:43 Tobias Waldekranz
2025-09-18 7:43 ` [PATCH 01/11] dm: Add helper to manage a lower device Tobias Waldekranz
2025-09-18 7:43 ` [PATCH 02/11] dm: linear: Refactor to make use of the generalized cdev management Tobias Waldekranz
2025-09-18 7:43 ` [PATCH 03/11] dm: verity: Add transparent integrity checking target Tobias Waldekranz
2025-09-18 13:06 ` Sascha Hauer
2025-09-18 7:43 ` [PATCH 04/11] dm: verity: Add helper to parse superblock information Tobias Waldekranz
2025-09-18 7:43 ` [PATCH 05/11] commands: veritysetup: Create dm-verity devices Tobias Waldekranz
2025-09-18 7:43 ` [PATCH 06/11] ci: pytest: Open up testfs to more consumers than the FIT test Tobias Waldekranz
2025-09-22 15:38 ` Ahmad Fatoum
2025-09-18 7:43 ` [PATCH 07/11] ci: pytest: Enable testfs feature on malta boards Tobias Waldekranz
2025-09-22 15:40 ` Ahmad Fatoum
2025-09-18 7:43 ` [PATCH 08/11] ci: pytest: Generate test data for dm-verity Tobias Waldekranz
2025-09-22 15:41 ` Ahmad Fatoum
2025-09-18 7:43 ` [PATCH 09/11] test: pytest: add basic dm-verity test Tobias Waldekranz
2025-09-22 15:44 ` Ahmad Fatoum
2025-09-18 7:43 ` [PATCH 10/11] ci: pytest: Centralize feature discovery to a separate step Tobias Waldekranz
2025-09-22 15:45 ` Ahmad Fatoum
2025-09-18 7:43 ` [PATCH 11/11] ci: pytest: Enable device-mapper labgrid tests Tobias Waldekranz
2025-09-22 15:46 ` Ahmad Fatoum
2025-09-18 14:08 ` [PATCH 00/11] dm: verity: Add transparent integrity checking target Sascha Hauer
2025-09-18 15:38 ` Tobias Waldekranz
2025-09-23 6:30 ` Sascha Hauer
2025-10-07 9:05 ` Ahmad Fatoum
2025-10-07 20:15 ` Tobias Waldekranz
2025-10-08 7:30 ` Ahmad Fatoum
2025-10-08 20:57 ` Tobias Waldekranz
2025-10-09 6:37 ` Ahmad Fatoum [this message]
2025-10-09 12:47 ` Tobias Waldekranz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24151bf4-46bb-466b-a2c8-b8324e4b9b9b@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=jre@pengutronix.de \
--cc=s.hauer@pengutronix.de \
--cc=tobias@waldekranz.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox