[U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

Heinrich,

[...]
> > >>>>Unfortunately, this is not practical right now because there is
> > >>>>already some sort of assumption (and consensus) that we would re-use
> > >>>>"Standalone MM services", which is already there in EDK2, as
> > >>>>secure storage for UEFI variables.
> > >>>>In the case, all the cache would be bypassed.
> > >>>>In my old prototype, I utilized the cache but dropped that feature
> > >>>>for several reasons.
> > >>>
> > >>>What has EDK2 code to do with it?
> > >>
> > >>Did you follow my comment below?
> > >>>>Unfortunately, this is not practical right now because there is
> > >>>>already some sort of assumption (and consensus) that we would re-use
> > >>>>"Standalone MM services", which is already there in EDK2, as
> > >>>>secure storage for UEFI variables.
> > >We are already working towards having StandAloneMM as an early OP-TEE TA.
> > >This will provide us with a secure variable storage for armv7/v8.
> > 
> > What would this OP-TEE binary do? - This seems to be a source of
> > misunderstanding when reviewing this patch.
> 
> I and Ilias will give you more details offline, here's a short(?)
> answer:
> 
> Standalone MM services here means a SPD entity which provides
> [Get|Set]Variable APIs to non-secure side firmware, that is
> currently EDK2. So the source code of Standalone MM services
> is included in EDK2 repository as a matter of fact.
> 
> Here is one drawback: It won't allow for other entities running
> concurrently on secure side. One example of useful secure feature
> is (software-based) TPM. So Linaro is working on modifying/transforming 
> Standalone MM to one OP-TEE application, which Ilias mentioned above.
> 
Exactly. The current StMM implementation exists for Armv8 *only* in SPM (Secure
Partition Manager). The idea is to make it an OP-TEE application, so we can run
it on on Armv7s as well. As Akashi-san mentions SPD (Secure Payload Dispatcher)
and SPM are mutually exclusive so having everything as OP-TEE trusted
applications gives us a number of advantages at the moment.

> > My guess is that OP-TEE is used to read non-volatile variables only once
> > when starting U-Boot and to write non-volatile variables whenever they
> > are changed.
> 
> So OP-TEE version of StMM is still on-going project and I assume
> that this OP-TEE app will support the same set of functionality/APIs
> as StMM does.
Yes that's the goal 

> 
> > All further reading of non-volatile variables and all access to volatile
> > variables will be handled by the U-Boot internal variable cache.
> > 
> > For volatile variables I would assume OP-TEE to never see them. This
> > requires that the U-Boot variable cachek supports reading from and
> > writing to the cache at runtime.
> 
> No. As far as I correctly understand, StMM handles volatile
> variables as well as non-volatile variables.
> EDK2 on non-secure side will redirect user's request directly
> to secure side even without *caching* variable's values.
> 
Similar understanding here. The question is, will we have to think of something
for non-arm architectures?

> > StandaloneMmPkg seems to be the hardware independent part of the
> > solution. Where will the hardware driver reside in your OP-TEE solution?
It depends on where your hardware is. If you have a NOR flash directly connected
to the secure world the answer is yes. 
For starters we are going to use RPMB + U-Boot supplicant.

> > 
> > Is the EDK2 hardware store for variables of the MACCHIATObin here:
> > edk2-platforms/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c?
No idea, i can ask around.

> > 
> > Which hardware platform will you use for testing the U-Boot development
> > of you OP-TEE driver?
> 
> Ilias will be able to answer those questions.
- stm32mp1 ST board based on armv7 [1]
- Socionext DeveloperBox for armv8 [2]. This has a running EDKII implementation
of StMM in SPM. The underlying firmware should be irrelevant though since the 
whole functionality is contained within an OP-TEE TA (trusted application). If i
remember correctly that will need an extra driver in OP-TEE (if we port U-Boot
on that)
- TI AM6 board [3]. I don't have the board in my hands yet, so no details on it


[1] https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html
[2] https://www.96boards.org/product/developerbox/
[3] http://www.ti.com/tool/PROCESSOR-SDK-AM65X 


Regards
/Ilias