Hello Masami-san,
From: Masami Hiramatsu masami.hiramatsu@linaro.org Hi Etienne,
Sorry for replying later.
2022年1月7日(金) 1:10 Etienne CARRIERE etienne.carriere@st.com:
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.
Hm.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence?
Yeah, I thought that the version ID comes from the capsule header.
I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
Who builds the capsule file. Or, should we decouple the version value from the capsule file?
I think it must be decoupled from the capusle file. When the BL2 loads the FIP partition, it should check anti-rollback counter against platform counter, so this anti-rollback counter should be tied to the FIP image, no?
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?
Hmm, if so, FWU metadata based multi-bank update itself is not secure. What happen if the first bootloader choose an incorrect (old) FIP image to load because of cracked FWU metadata?
It is (in my view), the task of the bootstage to ensure whatever images are to be booted that they match both authentication and version rollback protection. If metadata are fully corrupted, then device will be bricked, for sure. For platform where firmwares are stored in a non-secure storage media, next to kernel, filesystems etc..., we cannot overcome such DoS attack. Same case as a Linux kernel corrupting other parts of its filesystems storage media, preventing it from working.
Br, etienne
Thank you,
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.
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
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- Masami Hiramatsu
-- Masami Hiramatsu