On Wed, 6 May 2020 at 17:01, Grant Likely grant.likely@arm.com wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
The use of additional helpers such as shim, grub, efibootguard and their DTB handling as well as OS specific fixups (Linux, BSD...) should be out of scope of DTB handover discussion: should just be the GUID, memory type to be used, alignment. I think the only point to note is the DTB inside the table is immutable at the moment the EFIApp is called.
g.