mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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 |




  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