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>,
	Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 0/5] dm: Initial work on a device mapper
Date: Tue, 2 Sep 2025 10:40:43 +0200	[thread overview]
Message-ID: <7c59b735-a223-47a3-99ae-227617aee4fa@pengutronix.de> (raw)
In-Reply-To: <87h5xo3p9r.fsf@waldekranz.com>

Hi,

On 8/31/25 9:48 AM, Tobias Waldekranz wrote:
> On fre, aug 29, 2025 at 10:29, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> We are sort of in the same boat. We wrap our rootfs in an FIT header,
> just because that is the only format U-Boot knows how to verify. After
> verification, we strip off the header, mount it, and then sysboot from
> it, with the kernel and DTBs in /boot on the squash.
> 
> Just shipping the fs with verity data (+ possibly FEC, in the future)
> and a signature would be _so_ much nicer.

FEC with verity indeed sounds interesting. Apparently, it can go beyond
fixing occasional bit flips on read to even recover completely lost
blocks[1].

For the latter case, someone will need to implement some "blkhealthd"
that reads regularly and fixes up bit errors in the backing device.
Would also mesh nicely with retention on the medium itself as it gives
e.g. the eMMC a chance to correct ECC on infrequently used data before
it's completely irrecoverable.

[1]:
https://android-developers.googleblog.com/2016/07/strictly-enforced-verified-boot-with.html

>> Well I am very open for adding DM and dm-verity support to barebox. We
>> would likely have done it anyway at some point, but that could have
>> taken some time.
> 
> Cool! I did a toy implementation in Python yesterday, just to convince
> myself I understood how it works, and it was actually very straight
> forward. So if this series is eventually merged, I hope to follow up
> with an implementation of dm-verity pretty quickly.

Did you consider porting dm/dm-verity from the kernel instead and
decided against it?

I imagine there's a lot that would need to be dropped/adapted, but
having the same general structure may prove useful in future when adding
new device mapper targets. I can understand though, that for dm-verity
it may turn out to be easier to reimplement the functionality (which is ok).

Cheers,
Ahmad



> 
>> Sascha
>>
>> -- 
>> 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-09-02  9:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28 15:05 Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 1/5] string: add strtok/strtokv Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 2/5] dm: Add initial device mapper infrastructure Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 3/5] dm: linear: Add linear target Tobias Waldekranz
2025-08-29  5:56   ` Ahmad Fatoum
2025-08-28 15:05 ` [PATCH 4/5] test: self: dm: Add test of " Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 5/5] commands: dmsetup: Basic command set for dm device management Tobias Waldekranz
2025-08-29  8:29 ` [PATCH 0/5] dm: Initial work on a device mapper Sascha Hauer
2025-08-31  7:48   ` Tobias Waldekranz
2025-09-02  8:40     ` Ahmad Fatoum [this message]
2025-09-02  9:44       ` Tobias Waldekranz
2025-08-29 11:24 ` Ahmad Fatoum
2025-08-31  7:48   ` Tobias Waldekranz
2025-09-02  9:03     ` Ahmad Fatoum
2025-09-02 13:01       ` Tobias Waldekranz
2025-09-02 14:46       ` Jan Lübbe
2025-09-02 21:34         ` Tobias Waldekranz
2025-09-02 14:34   ` Jan Lübbe

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=7c59b735-a223-47a3-99ae-227617aee4fa@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --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