On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt 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> wrote:
On 11/26/20 7:40 PM, Sughosh Ganu wrote: > The Qemu platform emulator generates a device tree blob andplaces it
> at the start of the dram, which is then used by u-boot. Use thisdtb
> only if CONFIG_OF_BOARD is defined. This allows using a different > device tree, using the CONFIG_OF_SEPARATE option. This dtb isattached
> to the u-boot binary as a u-boot-fdt.bin file Dear Sughosh, thank your for this series which will allow us to betterdemonstrate and
test capsule updates. I am not sure if the approach that you take at device-trees here isthe
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 toadd
extra elements (the EFI signature list, see patch 2/14). Thus a device-tree might be loaded that does not match the user selected devices. An alternative approach would be to apply all additions to the device-tree as an FDT overlay (or fixup). This would allow thedynamic
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 the platform."
Jean-Jacques' patch series introduced some of the necessary code:
[PATCH PATCH v6 00/13] Add support for applications of overlays in SPL https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A...
CONFIG_OF_OVERLAY_LIST is used to specify the overlays to be compiled. 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 1) Generate a skeleton overlay dts file 2) Convert it to a dtb 3) 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?) 5) Load the overlay and apply it to the platform's dtb 6) Retrieve the certificate from the dtb at the time of capsule authentication
Embedding the certificate in the platform's dtb 1) 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.
-sughosh