Transfer List Checksum Correction and Impact on Bloblist

[Harrison Mutai]

+Ilias to the thread

On 30/09/2025 15:48, Tom Rini wrote:
> 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?
> 
Agreed, I raised your concerns in the specification forum [1], and 
similar concerns were raised by Ilias. It seems that the key question is 
whether any existing deployments rely on bloblist.

[1] https://github.com/FirmwareHandoff/firmware_handoff/issues/78