[U-Boot] [RFC] efi_loader: EFI variables

[Sumit Garg]

On Tue, 12 Feb 2019 at 21:45, Daniel Thompson
<daniel.thompson at linaro.org> wrote:
>
> On Tue, Feb 12, 2019 at 12:34:29PM +0100, Heinrich Schuchardt wrote:
> > On 2/12/19 10:49 AM, Alexander Graf wrote:
> > > On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
> > >> Hello Alex, hello Takahiro,
> > >>
> > >> this morning I met Daniel Thompson of Linaro. He thinks it would be
> > >> quite valuable if U-Boot would at least offer read access to EFI
> > >> variables at runtime.
> > >>
> > >> I think what it takes is only a RAM buffer that we put between our
> > >> current storage backend (i.e. synchronization with U-Boot variables)
> > >> and the API implementation.
> > >>
> > >> We will need such a buffer anyway for non-permanent variables once we
> > >> have a SPI flash storage.
> > >
> > > I think slowly we need to take a critical design decision: Do we want to
> > > be in the business of managing runtime UEFI variables?
> > >
> > > I don't have a fully cohesive answer to that yet. My gut feeling tells
> > > me, that runtime variables would be much better off if they lived in
> > > TrustZone. That way we don't have to play relocation tricks, and devices
> > > that give you persistency are owned by the secure world anyway, so there
> > > is no weird intersection between OS and RTS.
> > >
> > > So maybe the path forward would be to implement variable services in ATF
> > > (or OP-TEE rather I suppose) and just provide shim stubs to communicate
> > > with them from runtime services? That would keep all the variable logic
> > > platform agnostic, and we would not have to jump through weird hoops
> > > with DM.
> >
> > U-Boot' major asset are the many boards supported by drivers. Does ATF
> > or OP-TEE have drivers for SPI?
>
> Some ports have SPI drivers and AFAIK it is only really there to
> facilitate smartcard communications. I'm not aware of any SPI flash
> storage hooked up to the driver.
>

I think SPI flash driver in OP-TEE for variable storage should be doable.

>
> > Or is your idea that U-Boot would provide a module that is set up as a
> > trusted driver or trusted app, cf.
> > https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of-TEE%20copy.png
>
> OP-TEE has two implementations of secure storage at present: REE (rich
> OS) filesystem and eMMC RPMB.
>
> Things will get very circular when the secure storage is the REE
> filesystem because it is not available to OP-TEE until the REE has
> booted and started the supplicant. That means u-boot would have to
> provide a lot of supplicant infrastructure in order to read from the
> variable store.
>

AFAIK, u-boot does provide some supplicant infrastructure for eMMC
RPMB storage here:
drivers/tee/optee/supplicant.c
drivers/tee/optee/rpmb.c

But if we want to use this infrastructure for variable storage then we
need to make this as part of RTS.

-Sumit

>
> Daniel.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot