| Message ID | 20201126184110.30521-2-sughosh.ganu@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | qemu: arm64: Add support for uefi capsule update on qemu arm64 platform | expand |
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. Could you, please, assess the pros and cons of the two approaches with respect to: * usability for capsule updates * applicability for non-QEMU systems * integration of DTB overlays with FIT images for other use cases Best regards Heinrich > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > --- > board/emulation/qemu-arm/qemu-arm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c > index f18f2ed7da..e146d1cc50 100644 > --- a/board/emulation/qemu-arm/qemu-arm.c > +++ b/board/emulation/qemu-arm/qemu-arm.c > @@ -89,11 +89,13 @@ int dram_init_banksize(void) > return 0; > } > > +#if defined(CONFIG_OF_BOARD) > void *board_fdt_blob_setup(void) > { > /* QEMU loads a generated DTB for us at the start of RAM. */ > return (void *)CONFIG_SYS_SDRAM_BASE; > } > +#endif > > void enable_caches(void) > { >
hello Heinrich, On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt <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). 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 > Could you, please, assess the pros and cons of the two approaches with > respect to: > > * usability for capsule updates > * applicability for non-QEMU systems > * integration of DTB overlays with FIT images for other use cases > > Best regards > > Heinrich > > > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > > --- > > board/emulation/qemu-arm/qemu-arm.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/board/emulation/qemu-arm/qemu-arm.c > b/board/emulation/qemu-arm/qemu-arm.c > > index f18f2ed7da..e146d1cc50 100644 > > --- a/board/emulation/qemu-arm/qemu-arm.c > > +++ b/board/emulation/qemu-arm/qemu-arm.c > > @@ -89,11 +89,13 @@ int dram_init_banksize(void) > > return 0; > > } > > > > +#if defined(CONFIG_OF_BOARD) > > void *board_fdt_blob_setup(void) > > { > > /* QEMU loads a generated DTB for us at the start of RAM. */ > > return (void *)CONFIG_SYS_SDRAM_BASE; > > } > > +#endif > > > > void enable_caches(void) > > { > > > >
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 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 > > > Could you, please, assess the pros and cons of the two approaches with > respect to: > > * usability for capsule updates > * applicability for non-QEMU systems > * integration of DTB overlays with FIT images for other use cases > > Best regards > > Heinrich > > > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org > <mailto:sughosh.ganu@linaro.org>> > > --- > > board/emulation/qemu-arm/qemu-arm.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/board/emulation/qemu-arm/qemu-arm.c > b/board/emulation/qemu-arm/qemu-arm.c > > index f18f2ed7da..e146d1cc50 100644 > > --- a/board/emulation/qemu-arm/qemu-arm.c > > +++ b/board/emulation/qemu-arm/qemu-arm.c > > @@ -89,11 +89,13 @@ int dram_init_banksize(void) > > return 0; > > } > > > > +#if defined(CONFIG_OF_BOARD) > > void *board_fdt_blob_setup(void) > > { > > /* QEMU loads a generated DTB for us at the start of RAM. */ > > return (void *)CONFIG_SYS_SDRAM_BASE; > > } > > +#endif > > > > void enable_caches(void) > > { > > >
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 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://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. Best regards Heinrich > >> >> >> Could you, please, assess the pros and cons of the two approaches with >> respect to: >> >> * usability for capsule updates >> * applicability for non-QEMU systems >> * integration of DTB overlays with FIT images for other use cases >> >> Best regards >> >> Heinrich >> >> >> > >> > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org >> <mailto:sughosh.ganu@linaro.org>> >> > --- >> > board/emulation/qemu-arm/qemu-arm.c | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > diff --git a/board/emulation/qemu-arm/qemu-arm.c >> b/board/emulation/qemu-arm/qemu-arm.c >> > index f18f2ed7da..e146d1cc50 100644 >> > --- a/board/emulation/qemu-arm/qemu-arm.c >> > +++ b/board/emulation/qemu-arm/qemu-arm.c >> > @@ -89,11 +89,13 @@ int dram_init_banksize(void) >> > return 0; >> > } >> > >> > +#if defined(CONFIG_OF_BOARD) >> > void *board_fdt_blob_setup(void) >> > { >> > /* QEMU loads a generated DTB for us at the start of RAM. */ >> > return (void *)CONFIG_SYS_SDRAM_BASE; >> > } >> > +#endif >> > >> > void enable_caches(void) >> > { >> > >> >
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 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://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. -sughosh
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). 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://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. Best regards Heinrich > > -sughosh
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). 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://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
On 12/8/20 10:19 AM, Sughosh Ganu wrote: > > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk@gmx.de > <mailto: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> > > <mailto: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>> > > >> <mailto: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). 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. Wouldn't it be the enough for testing to apply an overlay with the public key using the fdt command? Best regards Heinrich
On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 12/8/20 10:19 AM, Sughosh Ganu wrote: > > > > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk@gmx.de > > <mailto: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> > > > <mailto: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>> > > > >> <mailto: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). 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
On 12/9/20 6:25 AM, Sughosh Ganu wrote: > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >> On 12/8/20 10:19 AM, Sughosh Ganu wrote: >>> >>> On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk@gmx.de >>> <mailto: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> >>> > <mailto: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>> >>> > >> <mailto: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). 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. Best regards Heinrich
On Wed, 9 Dec 2020 at 12:56, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 12/9/20 6:25 AM, Sughosh Ganu wrote: > > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk@gmx.de> > wrote: > > > >> On 12/8/20 10:19 AM, Sughosh Ganu wrote: > >>> > >>> On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk@gmx.de > >>> <mailto: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> > >>> > <mailto: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>> > >>> > >> <mailto: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). 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
On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 12/8/20 10:19 AM, Sughosh Ganu wrote: > > > > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk@gmx.de > > <mailto: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> > > > <mailto: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>> > > > >> <mailto: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). 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. > > Wouldn't it be the enough for testing to apply an overlay with the > public key using the fdt command? Is there a way I can build qemu such that the device-tree that is generated is with the __symbols__ node. Without this node, I am unable to apply the fdt overlay on the base platform devicetree. -sughosh
On 15.12.20 12:10, Sughosh Ganu wrote: > > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk@gmx.de > <mailto:xypron.glpk@gmx.de>> wrote: > > On 12/8/20 10:19 AM, Sughosh Ganu wrote: > > > > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt > <xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> > > <mailto:xypron.glpk@gmx.de <mailto: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> > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>> > > > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> > <mailto: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>> > > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>>> > > > >> <mailto:xypron.glpk@gmx.de > <mailto:xypron.glpk@gmx.de> <mailto:xypron.glpk@gmx.de > <mailto:xypron.glpk@gmx.de>> > > <mailto: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). 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://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>> > > > > > > <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. > > Wouldn't it be the enough for testing to apply an overlay with the > public key using the fdt command? > > > Is there a way I can build qemu such that the device-tree that is > generated is with the __symbols__ node. Without this node, I am unable > to apply the fdt overlay on the base platform devicetree. According to https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt __symbols__ is only needed if you refer to phandles in the overlay. When using paths instead __symbols__ is not required. I have not tested if this holds true for U-Boot too. Best regards Heinrich > > -sughosh
On Tue, 15 Dec 2020 at 18:25, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 15.12.20 12:10, Sughosh Ganu wrote: > > > > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk@gmx.de > > <mailto:xypron.glpk@gmx.de>> wrote: > > > > On 12/8/20 10:19 AM, Sughosh Ganu wrote: > > > > > > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt > > <xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> > > > <mailto:xypron.glpk@gmx.de <mailto: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> > > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>> > > > > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> > > <mailto: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>> > > > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de> > > <mailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>>> > > > > >> <mailto:xypron.glpk@gmx.de > > <mailto:xypron.glpk@gmx.de> <mailto:xypron.glpk@gmx.de > > <mailto:xypron.glpk@gmx.de>> > > > <mailto: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). 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://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 > >> > > > > > > > > > < > 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. > > > > Wouldn't it be the enough for testing to apply an overlay with the > > public key using the fdt command? > > > > > > Is there a way I can build qemu such that the device-tree that is > > generated is with the __symbols__ node. Without this node, I am unable > > to apply the fdt overlay on the base platform devicetree. > > According to > https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt > __symbols__ is only needed if you refer to phandles in the overlay. When > using paths instead __symbols__ is not required. > > I have not tested if this holds true for U-Boot too. > This does work. Thanks. I was referring to the document mentioned in the README.fdt-overlays[1] and that does not have mention of target-path. -sughosh [1] - https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt
diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c index f18f2ed7da..e146d1cc50 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -89,11 +89,13 @@ int dram_init_banksize(void) return 0; } +#if defined(CONFIG_OF_BOARD) void *board_fdt_blob_setup(void) { /* QEMU loads a generated DTB for us at the start of RAM. */ return (void *)CONFIG_SYS_SDRAM_BASE; } +#endif void enable_caches(void) {
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 Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> --- board/emulation/qemu-arm/qemu-arm.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.17.1