> -----Original Message----- > From: Bhupesh Sharma [mailto:bhsharma@xxxxxxxxxx] > Sent: Wednesday, April 25, 2018 6:06 PM > To: Leif Lindholm <leif.lindholm@xxxxxxxxxx> > Cc: Grant Likely <grant.likely@xxxxxxx>; Udit Kumar <udit.kumar@xxxxxxx>; > Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Pankaj Bansal > <pankaj.bansal@xxxxxxx>; mark.rutland@xxxxxxx; linux-efi@xxxxxxxxxxxxxxx; > Varun Sethi <V.Sethi@xxxxxxx>; Wasim Khan <wasim.khan@xxxxxxx>; > nd@xxxxxxx; Rod Dorris <rod.dorris@xxxxxxx> > Subject: Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration > table > > On Wed, Apr 25, 2018 at 4:20 PM, Leif Lindholm <leif.lindholm@xxxxxxxxxx> > 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. Hi Bhupesh This may fly, because you are updating whole DTB even if a part of this needs update for given OS. As I said in my previous email, we two problems 1/ Replacing whole DTB, due to OS upgrade Your proposed solution looks ok for this, even updating whole firmware image is also an option. 2/ Updating a part of firmware provided DTB, sort of overlays This will work as long as we have one OS/distribution to boot Regards Udit > 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.) > > ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
