[PATCH] efi_loader: Enable run-time variable support for tee based variables

[Ilias Apalodimas]

Hi Atish,

> >
> > diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
> > index 7a2dba7dc263..fd97d5b56300 100644
> > --- a/lib/efi_loader/efi_var_mem.c
> > +++ b/lib/efi_loader/efi_var_mem.c
> > @@ -10,7 +10,7 @@
> >  #include <efi_variable.h>
> >  #include <u-boot/crc.h>
> >
> > -static struct efi_var_file __efi_runtime_data *efi_var_buf;
> > +struct efi_var_file __efi_runtime_data *efi_var_buf;
>
> I am a bit confused how this will work. This means it will reside in GOT
> which is not mapped in virtual address for Linux. Whenever we try to
> invoke get_variable service, it will panic.
> Did we miss a trick in RISC-V ?
>
> Here are the details of the issue we are seeing.
>
> http://lists.infradead.org/pipermail/linux-riscv/2021-January/004200.html
>

Thanks for reporting this. I can't make too much from the dump itself. Since
there's a qemu config for riscv I'll reproduce it.

Long shot but, during LTO, the whole executable is compiled in one go. I think
that if in that phase it observes that GOT entries never change it converts
them to relative references. I think we are either looking into some compiler
differences here or maybe a linker script trick. In any case that's not the
right way to go.
FWIW I just tested on arm64 and my .got table is empty.

Since this will work if we switch it back to a static pointer, that
should be easy to
fix and the correct way to do it since we'll be unaffected by
compiler/linker changes.

In U-Boot we support 2 ways for runtime variables. One is generic, by using
a piece of runtime data memory for the variables and the other one is very arm
specific. In both cases though the runtime memory backend is used to expose
the variables to the kernel.  So that variable can remain static and instead
code a function internally to efi_var_mem.c and do the memcpy we need.

I've never tested it on risc-v but apparently I should up more tests for cases
like that.
I'll send a patch tomorrow once I gather all the objdump info to make
sure we aren't
missing anything.

Regards

/Ilias