On Wed, Apr 25, 2018 at 8:27 PM, Udit Kumar <udit.kumar@xxxxxxx> wrote: > > >> -----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 Well I am not sure how you are breaking down and viewing the DTB subsections (e.g. DTSI and DTS files) on the persistent storage device (as far as overlay are concerned). Normally the entire DTB blob is stored as a single entity on the persistent storage (flash/sd-card) - I think the same is true for u-boot as well where also we can pass the entire dtb blob via the 'bootm' command (and not a subsection of the same). AFAIK we can have different banks/blocks being used to store the DTB blob, but that is determined by the geometry of the storage device and not directly related to the DTB overlay and we cannot update selective persistent storage areas (banks/blocks) to update a part of DTB and be sure that the area being updated contains the right overlay. Also updating a part of DTB, might break existing secure updation mechanisms as for the secure verification of the DTB blob (on the persistent storage device), we treat the DTB blob as a single payload while passing it to the verification algorithm (e.g. SHA256). So, updating part of firmware provided DTB is perhaps a different point all together, but you can possibly use the following methodology to achieve something similar to the same (although we end up still flashing the entire DTB again on the persistent storage via the capsule update): 1. You can boot into a stable Linux version (may be a older stable kernel). 2a. Assuming that the .dtb for base platform is available under /boot 2b. You can obtain the overlay dts as an update (lets say via a networking interface). 2c. Using 'dtc' interpreter you can apply the overlay dts (which contains the delta changes over the base dts) # dtc -@ -I dts -O dtb -o output.dtbo overlay.dts 3. The dtb blob thus obtained can be passed as a (signed) capsule update to the firmware to be written to flash on the next reset. 4. Now when you read the grub2 selection screen you can select the new Linux image (upstream?) via the standard grub2 interface (which contains the new dts changes required by linux drivers) and boot into it. Now the drivers should not panic/error-out due to wrong/incompatible dts fields. Thanks, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
