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

[Sumit Garg]

+ tee-dev ML

On Tue, 12 Feb 2019 at 17:36, Alexander Graf <agraf at suse.de> wrote:
>
> On 02/12/2019 12:34 PM, 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?
> >
> > 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
>
> I think it's perfectly possible to build a special OP-TEE U-Boot target
> that can then reuse its drivers, similar to Simon's idea. But we should
> probably not try to target RTS with that, but only secure enclaves.
>

One of OP-TEE design goals [1] being:

Small footprint - the TEE should remain small enough to reside in a
reasonable amount of on-chip memory as found on Arm based systems.

I think this was one of main reason to have tee-supplicant
infrastructure in normal world to reuse drivers and keep small
footprint of OP-TEE.

So if we build a special OP-TEE u-boot target and link it with
optee-os as part of secure enclave then I am not sure how it will
align with above design goal.

[1] https://optee.readthedocs.io/general/about.html

-Sumit

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