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