Hi Etienne
Please see my replies inline. I have used below terminologies to avoid confusion
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?
> >
> > 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.
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.
> >
> > 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
> >
> > --
> > TF-A mailing list -- tf-a@lists.trustedfirmware.org
> > To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
> >
>
> --
> Masami Hiramatsu
ST Restricted
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org