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