On Wed, Apr 25, 2018 at 4:20 PM, Leif Lindholm <leif.lindh...@linaro.org> wrote: > On Wed, Apr 25, 2018 at 11:04:13AM +0100, Grant Likely wrote: >> On 25/04/2018 07:49, Udit Kumar wrote: >> > > 2) Kernel provides/overrides DTB >> > > The kernel always has the option of loading it's own DTB, either because >> > > firmware doesn't provide one, or it needs a newer DTB. This is similar >> > > to CONFIG_ACPI_CUSTOM_DSDT in ACPI land. However, if the kernel is >> > > overriding the DTB, then firmware has no part of it, and it should not >> > > be allowed to modify the DTB at ExitBootServices() time. >> > >> > For our platforms at least, this will not work unless firmware is doing >> > modifications. I think this I likely true for Ard as well. >> > Firmware has a logic to modify default DTB for available devices, reading >> > board configuration >> > programming required muxes, based upon this removing/adding devices >> > into DTB. >> > IMO, this will not be an optimal way to use untouched DTB provided by >> > kernel. >> >> Right, which is part of the reason for insisting on the firmare being >> responsible. If the kernel or Grub overrides the DTB, then it is an explicit >> *rejection* of anything firmware provides; presumable because something is >> broken and it has to be worked around. > > So, the functionality in GRUB to replace a firmware-provided > devicetree needs to go. And dtb= loading should ideally be made > dependent on some sort of DEBUG config option. > Suppliers that consider the DTB a feature of the kernel image need to > go back to appending it to the kernel image. > > And if overriding the firmware-provided system configuration is > necessary for booting at all, a trivial portable UEFI application can > be written to do that.
Having a UEFI application seems a good idea, but can't we explore using the standard UEFI capsule update method (and assign the DTB present on the persistent storage for e.g. flash as the subject of capsule update) from the OS to update the DTB and reboot into an updated firmware which contains the updated firmware. This seems very similar to how most UEFI vendors now supply new UEFI firmware deliverables/fixes and ask a user to apply on a running production system (without affecting the OS, grub being installed on the system). In the end, if we all agree that the DTB is to be passed via the firmware to the OS, we should be using the standard interfaces which are currently used for capsule update to update both the System firmware and Device firmware (especially since it allows us to sign a capsule as well). So, we have 3 options that we have discussed so far (please add if I have missed something here): 1. We rebuild the firmware from UEFI source which includes the dtb changes as per the changes pushed in upstream Linux/OS to be sure that the DTB in the firmware is in sync with the OS driver expectations. 2. We have a UEFI application which runs and updates the DTB. We can launch it automatically (as a part of startup script) or stop at the UEFI shell and launch the same. 3. We use the signed capsule update to update the DTB (considering it as a 'conceptual capsule' which is part of the 'system firmware' and occupies a defined area on the persistent storage). I am currently working at an approach to have option 3 supported for arm64 boards that I work on as I consider this to be the best option especially in view of the security considerations already taken care of in the signed capsule update and we need not worry about updating the OS or grub contents or recompile the UEFI firmware from source.Following are the (in-development) steps that I am working on currently: -> OS invokes the capsule update via the 'fwupd' tool (a standard capsule update tool which can be run from user-space). -> The capsule update contains an updated DTB (which can be signed). -> Firmware resets the system and processes the capsule image on the next boot using the EFI_FIRMWARE_MANAGEMENT_PROTOCOL (FMP). -> In case the capsule was signed its integrity can be checked using EFI_FIRMWARE_IMAGE_AUTHENTICATION protocol. -> The capsule update happens with the firmware updating the DTB contents on the persistent storage source. On current and subsequent boots the platform boots with a new firmware. Ofcourse, the above is still something that I have not finished implementing completely for my apm mustang board, but I think this can be a good approach to update dtb via (signed) capsule updates. Please let me know your comments. Thanks, Bhupesh > The thing I would like to add that is not just repeating myself is > just pointing out that "firmware" is not just EDK2/U-Boot. It is > entirely feasible that either of those inherit an already modified DTB > from an earlier firmware stage. (I.e., let's make sure we don't just > kick the GRUB problem one step up the stack.) > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
