Hello Jassi,
On Wed, 28 Sept 2022 at 17:17, Jassi Brar jassisinghbrar@gmail.com wrote:
Hi Etienne,
On Wed, Sep 28, 2022 at 2:30 AM Etienne Carriere etienne.carriere@linaro.org wrote:
Hello Jassi, Sughosh and all,
But a malicious user may force some old vulnerable image back into use by updating all but that image.
When the system boots with accepted images (referring to fwu-mdata regular/trial state), the platform monotonic counter is updated against booted image version number if needed, preventing older images to be booted when an accepted image has been deployed. @Jassi, does this answer your question?
As I said in my earlier post, I know we can employ security+integrity techniques to prevent such misuse. My point is FWU should still be implemented assuming no such technique might be available due to any reason, and we do the best we can. Just as we don't say lets not care about buffer-overflow vulnerabilities because the system can implement secure boot and other such techniques.
For example, the spec warns : "The metadata can be maliciously crafted, it should be treated as an insecure information source." So clearly the spec doesn't count on rollback and authentication mechanisms to be always available - and that is how it should be.
It is true fwu metadata content are not secure, as the GPT content itself. We cannot prevent OS from corrupting fwu-mdata partitions or the device GPT despite the boot sequence heavily relies on their information. When fwu mdata and GPT are not secure, FWU only allows updating boot image, it cannot secure them. Early boot stage (tf-a) is in charge of verifying booted images (authent. and rollback counter), whatever the booted images are.
Best regards, etienne
cheers.