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

[Alexander Graf]

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