[RFC 11/14] efi_loader: variable: export variables table for runtime access

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

Akashi-san,

On Wed, Mar 18, 2020 at 10:53:45AM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 17, 2020 at 08:37:47AM +0100, Heinrich Schuchardt wrote:
> > On 3/17/20 3:12 AM, AKASHI Takahiro wrote:
> > > There are platforms on which OS's won't be able to access UEFI variables
> > > at runtime (i.e. after ExitBootServices).
> > > With this patch, all the UEFI variables are exported as a configuration
> > > table so as to enable retrieving variables' values from the table, and
> > > later modifying them via capsule-on-disk if necessary.
> > 
> > I do not understand why we should expose our internal memory for holding
> > UEFI variables to the operating system. This might end up in users
> > trying to access the variables directly.
> 
> I think that you somehow misunderstand my code as it never exposes
> any "internal memory," although I don't know what it exactly means in
> this context.
> This configuration table is nothing but a list of data that represent
> all the UEFI variables in implementation-agnostic format.
> 
> > I do not understand why we should not keep the pointer in our private
> > memory.
> 
> Anyway, this patch naively implements Peter's proposal while I also
> submitted another patch[1] that allows HL-OS to use GetVariable
> interface directly via *caching*.

How are the two approaches going to affect existig tools (i.e efivar --list) to
read the variables?

> 
> Since how we should enable accessing UEFI variables at runtime is
> one of key issues, I'd rather discuss in boot-arch ML as I suggested
> in the cover letter.
> I have already re-activated the discussion there[2].
> Please make your comments there for wider audience.
> 
> [1] https://lists.denx.de/pipermail/u-boot/2019-June/371769.html
> [2] https://lists.linaro.org/pipermail/boot-architecture/2020-March/001149.html
> 
Will do

Regards
/Ilias