[PATCH 1/3 v2] efi_capsule: Move signature from DTB to .rodata

Simon Glass sjg at chromium.org
Tue Jul 20 19:42:11 CEST 2021


Hi Sughosh,

On Tue, 20 Jul 2021 at 07:32, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
>
> hi Simon,
>
> On Tue, 20 Jul 2021 at 18:20, Ilias Apalodimas <ilias.apalodimas at linaro.org> wrote:
>>
>> Hi Simon,
>> On Tue, 20 Jul 2021 at 15:33, Simon Glass <sjg at chromium.org> wrote:
>> >
>> > Hi Ilias,
>> >
>> > On Sat, 17 Jul 2021 at 08:27, Ilias Apalodimas
>> > <ilias.apalodimas at linaro.org> wrote:
>> > >
>> > > The capsule signature is now part of our DTB.  This is problematic when a
>> > > user is allowed to change/fixup that DTB from U-Boots command line since he
>> > > can overwrite the signature as well.
>> >
>> > Just to repeat my question since it looks like I didn't get a response
>> > on the last patch:
>> >
>> > Do you mean with the 'fdt' command?
>> > >
>> > If you mean the FDT fixups, they happen to a different DT, the one
>> > being passed to Linux.
>>
>> In some platforms the key is derived from the relocated DTB, which we
>> can overwrite. But I'll let Sughosh who figured it out explain the
>> details.
>
>
> On platforms where the dtb is concatenated with the u-boot image, using CONFIG_OF_SEPARATE, the fdt is also getting relocated to the main memory. We retrieve the public key from this dtb. By default, the fdtcontroladdr env variable is getting set to this relocated dtb address -- this address can also be accessed using the bdinfo command. Thus the public key can be modified before attempting the capsule update. Which is the reason why Ilias is moving the public key to the embedded rodata section.

You should be clearer about what problem you are trying to solve. Are
you worried about a script changing the DT? Or just it being writable
in general?

U-Boot itself is relocated also, including the rodata. So are you
using the public key from the original location? What if that is not
accessible after relocation?

There is also the 'fdt addr -c' command to find the control DT. It is
not expected to be written to though. So just protect the memory to
which it is relocated, or relocate it to a place that you can protect.

If the DT is writable it will affect U-Boot's operation, since that is
where all the config is stored. There is no point in pretending that
pulling one thing out of it and protecting it will result in any sort
of improvement. This needs to be done properly.

Regards,
Simon


More information about the U-Boot mailing list