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.lik...@arm.com> wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt
<xypron.g...@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
1) Firmware loads stock DTB into EfiACPIReclaimMemory
2) 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
1) Firmware loads stock DTB into EfiACPIReclaimMemory
2) 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
1) Firmware loads stock DTB into EfiACPIReclaimMemory
2) 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.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
