On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08.12.20 06:28, Sughosh Ganu wrote:
On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:
On 07.12.20 13:50, Heinrich Schuchardt wrote: > On 07.12.20 06:15, Sughosh Ganu wrote: >> hello Heinrich, >> >> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt <xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> >> <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>>> wrote: >> >> On 11/26/20 7:40 PM, Sughosh Ganu wrote: >> > The Qemu platform emulator generates a device tree blob and places it >> > at the start of the dram, which is then used by u-boot. Use this dtb >> > only if CONFIG_OF_BOARD is defined. This allows using a different >> > device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached >> > to the u-boot binary as a u-boot-fdt.bin file >> >> Dear Sughosh, >> >> thank your for this series which will allow us to better demonstrate and >> test capsule updates. >> >> I am not sure if the approach that you take at device-trees here is the >> right one. >> >> On QEMU the device-tree is generated on the fly by the QEMU binary >> depending on which devices the user has specified. >> >> Your idea is to replace this device-tree completely to be able to add >> extra elements (the EFI signature list, see patch 2/14). Thusa
>> device-tree might be loaded that does not match the userselected
>> devices. >> >> An alternative approach would be to apply all additions to the >> device-tree as an FDT overlay (or fixup). This would allow the dynamic >> parts of the QEMU device-tree still to be passed through. >> >> >> I will take a look at storing the public key as part of the fdt overlay, >> with a runtime fixup. Although, I think the issue that you are pointing >> to would be specific to Qemu and not other platforms. But I do see the >> merit in having the public-key certificate stored as part of an overlay. >> If I hit any issues while implementing this, I will get back to you. Thanks. >> >> -sughosh > > OpenSBI can supply a device-tree to U-Boot. So this would be an > equivalent case. > > Best regards > > Heinrich <sng_>: "I am unable to think of a simple and elegant way to generate the overlay dtb, since this would require creation of a corresponding dts file, compiling it into a dtb and then using this on theplatform."
Jean-Jacques' patch series introduced some of the necessary code: [PATCH PATCH v6 00/13] Add support for applications of overlays inSPL
https://lists.denx.de/pipermail/u-boot/2019-October/387653.html <https://lists.denx.de/pipermail/u-boot/2019-October/387653.html>https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A...
<https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A...
CONFIG_OF_OVERLAY_LIST is used to specify the overlays to becompiled.
You will have to remove the CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY and CONFIG_SPL_LOAD_FIT dependency.What i meant was that the process to generate the fdt overlay on the host, embed it with the public-key certificate is more cumbersome than the current solution. So, for comparing the embedding the pub-key cert in the fdt overlay, as against the platform dtb
Embedding the certificate in the overlay
- Generate a skeleton overlay dts file
- Convert it to a dtb
- Run it through the mkeficapsule utility to embed the pub-key
certificate in the overlay(dtb) 4) Store the overlay dtb on some nv storage on the platform(ESP
partition?)
- Load the overlay and apply it to the platform's dtb
- Retrieve the certificate from the dtb at the time of capsule
authentication
Embedding the certificate in the platform's dtb
- Run the platform's dtb through the mkeficapsule utility to embed
the pub-key certificate 2) Boot the platform with the platform's dtb 3) Retrieve the certificate from the dtb at the time of capsule authentication
You had mentioned OpenSBI passing the dtb to u-boot. Does the OpenSBI generate the device tree for the platform on the fly even for non-qemu platforms. If it does not, the dtb that OpenSBI uses can be run through the mkeficapsule utility to embed the certificate.
OpenSBI applies fix-ups before passing the device-tree. The prototype device-tree can either be built into OpenSBI or can be passed from an earlier firmware stage.
So, if qemu if the only platform where the device tree is generated on the fly, and passed along, based on the comparison that i have stated above for the two scenarios(overlay vs platform dtb), I feel that using the platform's dtb and embedding the certificate is more easier to use than using the overlay.
Even on the qemu platform, I retrieved the dtb from the platform, for the given set of devices and interfaces used, and then ran the dtb through the mkeficapsule utility.
-sughosh