Misalignment between checksum schemes in firmware handoff implementations

[harrisonmutai-arm]

The current firmware handoff specification mandates the use of an XOR checksum. However, in practice, most existing implementations (e.g. bloblist in U-Boot and libtl in TF-A) use a byte-sum instead. Since these implementations are already widely deployed, enforcing XOR strictly would break compatibility.

[sjg20]

Yes, I recall the decision and change here:

#17

We could perhaps change the spec back to byte sum?

[danh-arm]

OK, we've got a compatibility problem here. As I see it, we've got to at least accept that byte-sum is the default algorithm in-use and change the spec accordingly (in a new version). We would need to clarify in the spec that this applies retrospectively to 1.0.

Are there any implementations out there already that use XOR that we need to worry about? If so, I think we'd need to retrospectively say that 1.0 receivers can ignore the checksum. Alternatively, receivers could check both checksums and pass if either one passes, but that might be too messy to specify.

At the same time, we should decide whether we want to support XOR as well. If so, we could use another flag bit or 2 to indicate the checksum algorithm to use. Receivers would have to continue supporting at least the byte-sum algorithm. I guess the benefits of XOR still apply so I'd be in favour of that.

@jmarinho @jwerner-chromium You might want to comment.

[jmarinho]

The v1.0 spec specifies:

• the checksum is xor-based,
• flags[0] says if checksum is valid.

This may be a contrarian perspective :) .
Could we fix the non-compliant implementations and bring them to v1.0 compliance?

[danh-arm]

Well yes, fixing the implementations is the ideal choice but the original descriptions said these are already widely deployed. I'd question how widely deployed libtl is because it's so new but I guess the uboot bloblist implementation has been around for a while. I suppose the question really should be are there 1.0 implementations with the byte-sum checksum deployed in real products in the field? @harrisonmutai-arm @sjg20 do we know the answer to that? If it's just short term disruption to CIs then that's probably acceptable.

[harrisonmutai-arm]

For LibTL the impact is limited to a few virtual Arm platforms. Fwiw OP-TEE and EDK2 have their own implementations too. I don't believe these are being used on any physical devices either though.

[sjg20]

@danh-arm No I don't know how many devices are using this in the field. Firmware tends to be built as a bundle so even if it were in the field it wouldn't necessarily cause issues if we had a flag day and changed every project.

But I don't really see xor as having any great benefits over the sum, so changing the spec seems OK to me.

[jwerner-chromium]

I mean, I'm just not sure why we have a written specification and a long v0.9 trial period and then finally a day where we say "okay it is actually v1.0 and you can trust that it is final now", if we then go back and change things again just because one implementer screwed up. Like Simon said, the practical impact of realigning the U-Boot implementation to what the spec says now would probably be pretty minor.

It's true that the difference between the checksums is pretty minor, but XOR has a small advantage (easy to parallelize with larger register widths) which is why it was chosen, and I think more important is simply the fact that it was chosen. If I was a firmware project evaluating whether I want to adopt this spec, I think seeing it make a backwards-incompatible change shortly after the "final" version was released would be a big red flag.

[danh-arm]

OK, there seems to be consensus to fix the implementations.

@harrisonmutai-arm it looks like you're taking care of libTL and OP-TEE. @sjg20 - can you work with Harrison to fix uboot. Not sure if there are others we need to handle right now (EDK2?).

[danh-arm]

Hi @apalos - just a heads on this transfer list implementation misalignment. Maybe your team can help fix uboot and ensure consistency across components for Linaro reference platforms?

[harrisonmutai-arm]

@danh-arm the patches for those are already in-place [1] [2] and only require being integrated into their respective projects. For EDK2, I think Prachotan might be able to help with that, right @jmarinho?

[1] https://review.trustedfirmware.org/c/shared/transfer-list-library/+/42548
[2] OP-TEE/optee_os#7531

[apalos]

Hi @apalos - just a heads on this transfer list implementation misalignment. Maybe your team can help fix uboot and ensure consistency across components for Linaro reference platforms?

Thanks @danh-arm . We'll have a look

[apalos]

@danh-arm what about backwards compatibility though? If we make the change in U-Boot unconditional, then old TF-A + new U-Boot might brick the board. Same for New TF-A, old u-boot. Shouldn't we bump the version number and negotiate the checksum there?

[sjg20]

If we need to do that, I would rather change the spec. The xor thing is a very small benefit, if any, certainly none in the current implementations I've read. It was introduced quite late in the process, which perhaps explains why I unfortunately missed it with all the other tweaks I was dealing with.

My comment above was that firmware is generally built from source as a monolithic binary, so I was hoping that changing the impl would be OK, so long as all projects did it at the same time.

[danh-arm]

@apalos Further up in this issue there was discussion on providing backwards compatibility but the hope is that this would not be necessary, assuming that there are not yet real deployments out there with with a firmware update mechanism that could cause a TL sender/receiver mismatch. If you have any insight there, let us know.