On tis, sep 02, 2025 at 10:40, Ahmad Fatoum <[email protected]> wrote: > Hi, > > On 8/31/25 9:48 AM, Tobias Waldekranz wrote: >> On fre, aug 29, 2025 at 10:29, Sascha Hauer <[email protected]> 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].
Yes, this is very exciting! Today, we use a classic A/B partition scheme for redundancy, but I would much rather have a setup where you install one or more versions of Infix, and all versions are always "redundant" in that the image ships with its own parity data. For users I think this also makes more sense: rather than configuring a boot order based on partitions, you specify which versions you want to boot and in what order. > 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? "Implmentation" was maybe being to generous to myself :) It was more or less an exercise to figure out which subset of dm-verity-target.c from the kernel that we need to extract to Barebox. > 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). The I/O paths are very different, so the .map() method that targets implement on the kernel side, based on a struct bio, felt a bit awkward to replicate in Barebox, so I went for .read()/.write() instead, to map cleaner to the existing block device interface. In general, the kernel does lots of performance enhancing tricks with async I/O etc. Basic device creation, based on a target table as the input, is the same, with the same format as the kernel. Target creation from an argument vector is also the same as in the kernel. I chose to go with .create()/.destroy() over (at least to me somewhat idiosyncratic) .ctr()/.dtr() - but I am happy to keep this closer to the original, if you prefer. Like in the kernel, each target reports its own status. I chose to start with something simple here, rather than copying the kernel's many different output variants etc. > 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 |
