Security and correctness issues around captured FDT pointers

[Minda Chen]

On 2023/11/16 8:25, Bo Gan wrote:
> On 11/13/23 9:29 AM, Anup Patel wrote:
>>
>> Yes, #1 is mostly safe.
>>
>> The #2 needs to be fixed in the generic/starfive/jh7110.c and all other places
>> where it exists.
>>
>> We should certainly stop accessing FDT after cold boot hard is done but I don't
>> think we should zero-out pointers as well.
>>
> Thanks for the reply, Anup. I did a little bit more digging on this and I think
> #1 is only safe when OpenSBI's carrying the FDT itself (through FW_FDT_PATH).
> Otherwise, we have to make sure FDT will never be accessed after cold boot done.
> By zeroing-out the pointers, we can avoid speculative access as well. This helps
> to defense against speculative timing attacks. (Maybe I'm too paranoid?).
> 
> Given OpenSBI starts at very early stage, it's probably uncommon to not have
> FW_FDT_PATH defined. I have a JH7110 on hand, and the OpenSBI (loaded by U-Boot
> SPL) will carry the FDT built from U-Boot. I'd imagine other boards/vendors do
> it similarly. Just in case folks really don't have FW_FDT_PATH, can we emit a
> warning, and suggest the FDT to be protected through other mechanism?
> 
> For #2, can @Minda Chen or @Wei Liang help take a look? I see no reason to have
> the `const char *compatible` field in `struct pmic`. The compatible string is
> always going to be "stf,axp15060-regulator" in the current implementation, so
> what's point of strcmp it again in `pmic_ops`? If it's for future extension,
> can you strcmp it inside `pm_reset_init`, and use an enum to indicate the model?
> 
> Bo
Now just one pmic now. the compatible can be deleted.

But I don't know what are you changed and 1#  2# mean. I can not find your patch in opensbi mail website.