Hello Manish,
Sorry of the late response.
On Fri, 7 Jan 2022 at 19:09, Manish Badarkhe Manish.Badarkhe@arm.com wrote:
Hi Etienne
Please see my replies inline. I have used below terminologies to avoid confusion
Anti-rollback counter – Present in the certificate Platform NV-counter – Present in the hardware
Thanks, i'll try to use the appropriate wording.
Regards
Manish Badarkhe
From: Etienne CARRIERE via TF-A tf-a@lists.trustedfirmware.org Date: Thursday, 6 January 2022 at 16:10 To: Masami Hiramatsu masami.hiramatsu@linaro.org Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org, Jose Marinho Jose.Marinho@arm.com Subject: [TF-A] Re: fw update & anti-rollback versioning
Hello Masami-san
-----Original Message----- From: Masami Hiramatsu masami.hiramatsu@linaro.org Sent: Wednesday, January 5, 2022 3:27 PM Subject: Re: [TF-A] fw update & anti-rollback versioning
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?
The version value comes with the update images and should have the same level of confidence as the images content themselves. I think the version info should be authenticated using existing FIP certificates support.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence? I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
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?
FWU metadata is also manipulated by non-secure world, so I don't think is can content such a sensitive data. Make sense?
Best regards, Etienne
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE: 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.
IMO keeping single version for FIP may not work as it contains both Trusted and Non-Trusted Images and we can’t compare it against either Trusted or Non-Trusted platform NV-counter. However, we can add FIP version but it will only get used for sanity purpose.
We already have ‘version’ field inside each image certificate. Platform already use this field in TBBR flow to compare it against platform NV-counter. All Trusted and Non-Trusted FW versions gets compared against Trusted and Non-Trusted platform NV-counter respectively.
Currently, all Trusted FWs hold same value, likewise for Non-Trusted FWs also. If we are looking to have every FW image have its own version value then platform must support NV-counter per image. Does ST platform supports multiple NV-counters?
No, our platforms usually don't have much NV monotonic counters the boot stage can reach. Using a single platform NV counter for the whole single update-able FIP image would be very convenient. But maybe that requirement to is too specific.
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.
I think you mean here to maintain separate ‘anti-rollback counter’ and “version” field in the image certificate. We like to know the use case how it will get consumed during the FW update flow.
Not really. The current issue is rather that platform NV-counter are being upgraded when anti-rollback NV counters in certificates have increased. This does allow update trials that should allow reverting to the last accepted image set, that must conform to platform NV-counters.
Do you want to use per image “anti-rollback counter” value to update its corresponding platform NV-counter, and per image version field only for the comparison against its platform NV-counter.
I have no real strong opinion here. If certification version fields a standard way to manage certificate updates/upgrades, then I think it is a this field can be a good place to store anti-rollback counters.
If expecting a single rollback counter for the FIP image protection, it cannot be relate to the certificate version field.
Req3:
The version field should be present even if the FIP does not contain
image certificates.
Can you use in this case (Non-TBBR flow) same FIP version explained above?
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
-- Masami Hiramatsu