Hi Etienne,

It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?

This anti-rollback counter may depend on the FWU multi-bank update.

If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media.

To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).

What would you think?

Thank you,

2022年1月5日(水) 19:23 Etienne CARRIERE via TF-A <tf-a@lists.trustedfirmware.org>:

Dear all,
(and may the new year be happy to you and your beloved)

In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:

Req1:
The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.

Req2:
We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.

Req3:
The version field should be present even if the FIP does not contain image certificates.

Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.

Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?

Best regards,
Etienne Carriere

ST Restricted
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org