Hi Heinrich,
[...]
+/**
- fwu_get_image_alt_num() - Get the dfu alt number to be used for capsule update
- @image_type_id: image guid as passed in the capsule
- @update_bank: Bank to which the update is to be made
- @alt_num: The alt_num for the image
- Based on the guid value passed in the capsule, along with the bank to which the
- image needs to be updated, get the dfu alt number which will be used for the
- capsule update
- Return: 0 if OK, -ve on error
- */
+int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
int *alt_num)+{
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.
You are assuming here an attacker can manipulate the metada to trigger a DoS by overwriting wrong parts of the flash. However there's an easier way to trigger that. If he already has access, he can completely erase the metadata and their backup GPT. You then get the same result a device that cant boot. Is there any scenario you have in mind that storing those as part fo the capsule would help? The way I see it unless we have the metadata and the firmware stored in a flash in the secure world, I don't see a sensible way to protect against those kind of attacks.
The signed capsule would be a good place for storing the DFU mapping.
[...]
Thanks for taking the time with this! Regards /Ilias