[RESEND RFC PATCH 03/10] FWU: Add metadata structure and functions for accessing metadata

[Sughosh Ganu]

hi Ilias,

On Wed, 1 Dec 2021 at 13:20, Ilias Apalodimas <ilias.apalodimas at linaro.org>
wrote:

> Hi Sughosh,
>
> [...]
> >> > +{
> >> > +     struct fwu_metadata_ops *ops;
> >>
> >> The metadata is an untrusted information source and hence MUST NOT be
> >> used to map the image_type_id to the DFU alt_number. Don't invite for an
> >> denial of service attack.
> >>
> >> The signed capsule would be a good place for storing the DFU mapping.
> >
> >
> > I understand your concern with using dfu_alt_info for storing the
> information needed for writing the capsule payload. However, putting the
> information currently stored on the dfu_alt_info on a capsule should
> require a spec change IMO. This should first be discussed and brought in as
> part of the UEFI spec.
>
> Well not the UEFI spec.  You got the FMP driver which is abstract
> enough to handle that.  However as I already replied to Heinrich and
> attacker can just erase the entire GPT,  instead of bothering altering
> it.  So what I've been trying to think based on Heinrich's suggestion
> is if an attacker can manipulate the metadata in such a way to force
> the device boot something it shouldn't.  But since BL1 will go ahead
> and verify signatures before booting them anyway,  I can't think of
> something valid.
>

Sorry, I misinterpreted the comment from Heinrich. I was replying to the
comment from Heinrich about not using the dfu_alt_info env variable for the
updates. I think Heinrich is also suggesting putting the metadata
equivalent information on the capsule. This would also mean adding a header
to each payload where the header stores the metadata information. But as
you say, having the firmware and the metadata on a device that can be
accessed from the non-secure world, we cannot avoid DoS attacks even with
the metadata on the capsule. Also, this would mean having multiple copies
of the metadata, since the earlier stage bootloader(BL2/spl) shall still
need the metadata on a storage device partition to identify which bank to
boot from.

-sughosh


>
> > Also, when you say signed capsule, please note not the entire capsule
> gets signed -- it is only the capsule payloads that are signed, not the
> headers. So putting the information currently stored in dfu env var to the
> capsule would mean adding a header to the payload, which would contain this
> information, and then the header plus payload would be signed. However this
> is > implemented, this would mean changes to the current capsule format,
> and making this change without changing the spec would also mean that we
> will also not be able to use the GenerateCapsule tool for capsule
> generation. This is not a small change which can be included as a patch in
> the FWU A/B update series, but should be taken up as a separate exercise.
> >
>
> [...]
>
>
> Cheers
> /Ilias
>