hi Ilias,
On Wed, 1 Dec 2021 at 13:20, Ilias Apalodimas ilias.apalodimas@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