Transfer List Checksum Correction and Impact on Bloblist

[Tom Rini]

On Tue, Sep 30, 2025 at 11:53:22AM +0100, Harrison Mutai wrote:
> On 29/09/2025 19:11, Tom Rini wrote:
> > On Fri, Sep 26, 2025 at 05:09:53PM +0100, Harrison Mutai wrote:
> > > Hi all,
> > > 
> > > We recently applied changes to the transfer list library [1] to correct the
> > > checksum calculation. Previously, we used a simple byte-sum approach.
> > > However, we later realized this contradicts the Firmware Handoff
> > > specification, which states:
> > > 
> > > > The checksum is set to a value such that the XOR over every byte in the
> > > > {tl_base_pa, …, tl_base_pa + used_size - 1} address range is equal to 0.
> > > 
> > > This discrepancy creates problems when interoperating with Bloblist.
> > > Should Bloblist’s checksum calculation be updated to follow the same
> > > XOR-based method?
> > > 
> > > [1]
> > > https://review.trustedfirmware.org/c/shared/transfer-list-library/+/42548
> > 
> > Erm, since this has been out in the wild so to speak, we can't just
> > change the algorithm without bumping some cardinal. Or are there yet
> > other implementations that were doing what the spec said?
> > 
> 
> Raymond; Thanks for setting up the handoff tests. The next release for TF-A
> is planned for mid-November [1].
> 
> We’ve run into an issue where TF-A requires specific tags from the transfer
> list library, but we can’t consume them due to the recent checksum changes.
> 
> Tom; As it stands, ours is the only implementation currently using the
> updated checksum algorithm. There are two other consumers - OP-TEE and EDK2.
> OP-TEE already has a patch in upstream review to move to the new algorithm
> [2].
> 
> I’ve also reached out to the author of the EDK2 implementation to make them
> aware of the change.
> 
> [1] https://trustedfirmware-a.readthedocs.io/en/latest/about/release-information.html
> [2] https://github.com/OP-TEE/optee_os/pull/7531

OK, but since this could also be deployed, I'm again asking, can we make
a breaking change like this without having to check some cardinal /
version field / something? A mismatch in expected algorithms will break,
and so updating deployed devices and getting a mismatch is possibly
bricking the device?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250930/718050e3/attachment.sig>