All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Sughosh Ganu <sughosh.ganu@linaro.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	 AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Masami Hiramatsu <masami.hiramatsu@linaro.org>,
	 Alexander Graf <agraf@csgraf.de>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 1/3 v2] efi_capsule: Move signature from DTB to .rodata
Date: Tue, 20 Jul 2021 11:42:11 -0600	[thread overview]
Message-ID: <CAPnjgZ1nD9E70sCnAuwqakicSwz-1iawjn3t6EYPH7VC8hG=uA@mail.gmail.com> (raw)
In-Reply-To: <CADg8p967fw0rpdwNkRgvXAj+=Z4V1hRRKnqCtWAr2-S02r_PPg@mail.gmail.com>

Hi Sughosh,

On Tue, 20 Jul 2021 at 07:32, Sughosh Ganu <sughosh.ganu@linaro.org> wrote:
>
> hi Simon,
>
> On Tue, 20 Jul 2021 at 18:20, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>>
>> Hi Simon,
>> On Tue, 20 Jul 2021 at 15:33, Simon Glass <sjg@chromium.org> wrote:
>> >
>> > Hi Ilias,
>> >
>> > On Sat, 17 Jul 2021 at 08:27, Ilias Apalodimas
>> > <ilias.apalodimas@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

  reply	other threads:[~2021-07-20 17:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-17 14:26 [PATCH 1/3 v2] efi_capsule: Move signature from DTB to .rodata Ilias Apalodimas
2021-07-17 14:26 ` [PATCH 2/3] mkeficapsule: Remove dtb related options Ilias Apalodimas
2021-07-17 14:26 ` [PATCH 3/3] doc: Update CapsuleUpdate READMEs Ilias Apalodimas
2021-07-20 12:33 ` [PATCH 1/3 v2] efi_capsule: Move signature from DTB to .rodata Simon Glass
2021-07-20 12:50   ` Ilias Apalodimas
2021-07-20 13:31     ` Sughosh Ganu
2021-07-20 17:42       ` Simon Glass [this message]
2021-07-21  6:41         ` Ilias Apalodimas
2021-07-22 13:28           ` Simon Glass
2021-07-22 13:29             ` Simon Glass
2021-07-22 13:55               ` Ilias Apalodimas
2021-07-22 16:46                 ` Simon Glass
2021-07-22 20:54                   ` Ilias Apalodimas
2021-08-01 23:53                     ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPnjgZ1nD9E70sCnAuwqakicSwz-1iawjn3t6EYPH7VC8hG=uA@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=agraf@csgraf.de \
    --cc=ilias.apalodimas@linaro.org \
    --cc=masami.hiramatsu@linaro.org \
    --cc=sughosh.ganu@linaro.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.