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
