On Thu, Jul 9, 2026 at 9:16 PM Simon Glass <[email protected]> wrote:
> Just on this point, the question is really whether GRUB does not touch > it. My understand is that it actually loads the FDT from a file (Ilias > is the expert here) and that is why we have an EFI fix-up protocol to > send that loaded FDT back to U-Boot to be fixed up before booting. Oh, ok, good point. Now, there are two cases: 1. If grub.cfg does not execute the `devicetree` command, GRUB uses the firmware-provided FDT from the EFI configuration table. This is the path I tested (most common in stock distro images?) 2. If grub.cfg executes `devicetree <file>`, GRUB loads that FDT and can replace the configuration-table entry before starting Linux. Debian/Ubuntu GRUB also carries the EFI_DT_FIXUP_PROTOCOL support, so the loaded FDT is passed back to U-Boot before GRUB installs it. The mechanism proposed in this RFC (V2) guarantees that the selected and verified firmware FDT is the one presented to the initial EFI application. It does not make that configuration-table entry immutable after the EFI application starts. After all an EFI application can use InstallConfigurationTable() directly, so trying to enforce immutability in the firmware-FDT loader would not be sufficient in any case. BTW this also means that authentication of the firmware FIT covers the DT provided by firmware, but not a later DT deliberately loaded by the EFI boot manager (we cannot do much about that). The good news on this front is that (AFAICT) in a Secure Boot configuration GRUB's `devicetree` command is normally lockdown-restricted (but again that is a policy enforced by GRUB rather than by this mechanism). In general I think that is correct rather than a hole: same precedence as passing a DT to bootefi, an explicit devicetree beats the firmware default, and firmware cannot stop a loaded image from installing a configuration table anyway. Hope this works, cheers. -- Carlo Caione
