[PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined
Heinrich Schuchardt
xypron.glpk at gmx.de
Wed Dec 9 08:26:29 CET 2020
On 12/9/20 6:25 AM, Sughosh Ganu wrote:
> On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk at 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 at gmx.de
>>> <mailto:xypron.glpk at gmx.de>> wrote:
>>>
>>> On 08.12.20 06:28, Sughosh Ganu wrote:
>>> >
>>> > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt
>>> <xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>
>>> > <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at 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 at gmx.de <mailto:xypron.glpk at gmx.de>
>>> <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>>
>>> > >> <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>
>>> <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at 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
More information about the U-Boot
mailing list