Hi Takahiro, On Thu, 5 Aug 2021 at 18:13, KASHI Takahiro <takahiro.aka...@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.g...@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 > > > >