[PATCH v2 0/3] efi: Minimal revert to rodata change
Simon Glass
sjg at chromium.org
Fri Aug 6 02:33:09 CEST 2021
Hi Takahiro,
On Thu, 5 Aug 2021 at 18:13, KASHI Takahiro <takahiro.akashi at linaro.org> wrote:
>
> On Thu, Aug 05, 2021 at 09:46:07AM -0600, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Thu, 5 Aug 2021 at 09:29, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > >
> > >
> > >
> > > On 02.08.21 16:44, Simon Glass wrote:
> > > > The changes to move from devicetree to rodata take things in the wrong
> > > > direction for various reasons:
> > > >
> > > > - devicetree is where config should be stored
> > >
> > > We are not talking about configuration here at all.
> >
> > I thought we were talking about the public key. That is run-time
> > config in my book, just like the devicetree itself, which controls all
> > the devices.
> >
> > >
> > > > - it provides no memory production in any case, particularly when U-Boot
> > >
> > > No clue what you mean by "memory production".
> >
> > memory protection. But it turns out this is pointless anyway. We
> > discussed it at length in the contributor call. We came down to one
>
> What was clarified and decided in that meeting?
> I know you have a meeting note, but it was not very clear for me
> which direction the discussion is heading now.
https://bit.ly/3bFvwA1
I don't think anything was decided, despite the time taken, but we did
talk through a lot of the issues.
>
> # Yes, I should have been there, but ...
> # Simon, if possible, please announce the agenda a bit earlier
> # so that I can notice that. I'm usually in the bed at that time :)
The agenda in this case was added some days in advance but as one
participant was a bit late we moved to the 'last-minute' topic of this
thread.
Also note that I don't set the agenda, although I might add a topic if
there is nothing there.
If you are in Asia, we used to have an Asia call but it was not well
attended so we dropped it.
>
> I don't think that memory protection is really a matter if there is
> no assumption that the storage where the firmware resides are
> securely protected.
OK. If it does matter, we can solve it.
Regards,
SImon
>
> -Takahiro Akashi
>
> > issue with the way the firmware is packaged by users (with U-Boot
> > coming from one place and TF-A another). I think Ilias is going to
> > write something up to help get to the bottom of it.
> >
> > >
> > > > is relocated
> > > > - testing becomes harder, with the suggestion of adding an entire new
> > > > sandbox build just for this
> > >
> > > Having an extra config is not required when putting the certificate into
> > > .rodata.
> >
> > The certificate should not go in rodata, period. Please just fix it.
> > It use to be fine a few weeks ago so it should not be hard.
> >
> > Regards,
> > Simon
> >
> > >
> > > Best regards
> > >
> > > Heinrich
> > >
> > > >
> > > > Revert this until a new direction can be established.
> > > >
> > > > Changes in v2:
> > > > - Also revert two other patches, based on comment from Takahiro
> > > >
> > > > Simon Glass (3):
> > > > Revert "doc: Update CapsuleUpdate READMEs"
> > > > Revert "mkeficapsule: Remove dtb related options"
> > > > Revert "efi_capsule: Move signature from DTB to .rodata"
> > > >
> > > > board/emulation/common/Makefile | 1 +
> > > > board/emulation/common/qemu_capsule.c | 43 ++++
> > > > doc/board/emulation/qemu_capsule_update.rst | 203 +++++++++++++++++
> > > > doc/develop/uefi/uefi.rst | 125 -----------
> > > > include/asm-generic/sections.h | 2 -
> > > > lib/efi_loader/Kconfig | 7 -
> > > > lib/efi_loader/Makefile | 8 -
> > > > lib/efi_loader/efi_capsule.c | 18 +-
> > > > lib/efi_loader/efi_capsule_key.S | 17 --
> > > > tools/mkeficapsule.c | 229 +++++++++++++++++++-
> > > > 10 files changed, 472 insertions(+), 181 deletions(-)
> > > > create mode 100644 board/emulation/common/qemu_capsule.c
> > > > create mode 100644 doc/board/emulation/qemu_capsule_update.rst
> > > > delete mode 100644 lib/efi_loader/efi_capsule_key.S
> > > >
More information about the U-Boot
mailing list