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 Best regards Heinrich _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot