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

[Ilias Apalodimas]

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.

> 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