On Wed, 9 Dec 2020 at 12:56, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
> On 12/9/20 6:25 AM, Sughosh Ganu wrote: > > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: > > > >> On 12/8/20 10:19 AM, Sughosh Ganu wrote: > >>> > >>> On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.g...@gmx.de > >>> <mailto:xypron.g...@gmx.de>> wrote: > >>> > >>> On 08.12.20 06:28, Sughosh Ganu wrote: > >>> > > >>> > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt > >>> <xypron.g...@gmx.de <mailto:xypron.g...@gmx.de> > >>> > <mailto:xypron.g...@gmx.de <mailto:xypron.g...@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.g...@gmx.de <mailto:xypron.g...@gmx.de> > >>> <mailto:xypron.g...@gmx.de <mailto:xypron.g...@gmx.de>> > >>> > >> <mailto:xypron.g...@gmx.de <mailto:xypron.g...@gmx.de> > >>> <mailto:xypron.g...@gmx.de <mailto:xypron.g...@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). 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 > >>> > 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 > 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://lists.denx.de/pipermail/u-boot/2019-October/387653.html> > >>> > > >>> < > 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&archive=both > >>> < > >> > https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both > >>> > >>> > > >>> < > >> > https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both > >> < > >> > https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both > >>>> > >>> > > >>> > 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. > >>> > >>> 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 > >> > >> As I understand the whole series is not about productive firmware > >> updates for QEMU but about a demonstration how it could be used and > >> allowing testing. > >> > > > > True, but the process of embedding the public key certificate into the > > platform's dtb for use in capsule authentication can be common for all > > platforms. If you are fine, we can keep this patch to be used on other > > non-qemu platforms, while i work on the overlay method for qemu. Will you > > be fine with this approach. > > > > -sughosh > > > > This patch only changes board/emulation/qemu-arm/qemu-arm.c. Hence "keep > this patch to be used on other non-qemu platforms" is not applicable to > this specific patch. > Sorry, i did not mean this patch, but patch 02/14, "mkeficapsule: Add support for embedding public key in a dtb". I meant that that patch can be used for other non-qemu platforms. -sughosh