Re: [PATCH v10 10/15] FWU: Add support for the FWU Multi Bank Update feature

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

Hi Jassi, 

On Wed, Sep 28, 2022 at 10:16:53AM -0500, Jassi Brar 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.

We've discussed this extensively during drafting the spec.  You are right
that we would be better off trying to protect the fwu metadata somehow.  In
fact Heinrich had similar concerns when the original RFC was posted.  i

But can you think of such a reliable mechanism?  The only thing
we could come up without overcomplicating the entire spec was a device that
boots from the secure world and stores the metadata either in a flash there
or a device with such protection mechanisms (e.g an RPMB).

Cheers
/Ilias

> 
> cheers.