On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
On 06/05/2020 15:21, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB
a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader 3) ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config ---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
This doesn't make sense to me. EFI boot does not use /memory nodes in the first place (or /memreserve/s), but the OS does not even install the DTB back into the config table array. In Linux, the EFI stub just passes its address in memory via r0, because that is what the bare metal boot protocol stipulates.
Ah right, I forgot about that detail. Ignore the bits about /memory. My intent wasn't to be super-accurate at this point, but to start a chat about what firmware updates may need to be applied to a replacement DTB.
So whatever is in the config table array when the OS loader executes is what it will consume. It is fine if some intermediate agent replaces the DTB entirely, but the firmware should not expect to be able to make any changes to it once it hands off to the next boot stage.
This is essentially why I brought this up: the firmware should provide the DTB. We know that in reality, people used DTBs shipped with the OS, and this is not great but acceptable. If we allow firmware to have a reverse dependency on the DTB, we make this dependency hell only worse, since you may find yourself in the situation where your kernel does not support the DT shipped with your firmware, and your firmware does not support the DT shipped with your kernel.
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.
To clarify; I was not talking about the kernel's EFI stub in any scenario. I was asking about other EFI applications making changes before the kernel stub is called.
g.