On 05/05/2020 08:30, Andrei Warkentin wrote:
*From:* Ard Biesheuvel ard.biesheuvel@arm.com
Not a strong position, but you may also want to put the foot down on *when* the exposed Devicetree blob must be consistent (consistent with some firmware setting changes). Perhaps thats at ReadyToBoot or ExitBootServices.
ReadyToBoot is a PI concept, not a UEFI concept. And EBS() is way too late. But I don't think there is any need to specify this: the firmware needs to make the DT available before calling the OS loader - I don't think we need to spell that out.
But this brings something else to mind: in the past, we had to push back on efforts to upstream Linux changes to install the DTB back into the configuration table, so that at EBS() time, the firmware would see the modified version. *That* is something we should rule out:
Got it. Agreed.
Needs to be worded carefully since it is a valid use case to replace the DTB entirely before ExitBootServices(). It needs to be clear that firmware is not required to consume the DTB if it gets replaced.
How about:
+If an OS Loader or other EFI application loads a new DTB that replaces +the DTB provided by firmware and registers it into the EFI_SYSTEM_TABLE, then firmware must not parse, modify, or +otherwise use the data contained in the new DTB. +In this scenario, the application becomes wholly responsible for the DTB data.
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.