On 6/19/19 7:13 AM, Ilias Apalodimas wrote:
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
Do I understand it write:
In U-Boot we would have code that essentially provides the functionality of EDK2's EFI_SMM_VARIABLE_PROTOCOL. Like MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c this would talk via SMI calls with the hardware drivers, in this case the OP-TEE app.
This would allow the OP-TEE app to be used both in U-Boot and in EDK2?
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?
The design should be open for other architectures. If we use the EFI_SMM_VARIABLE_PROTOCOL as the interface we should be able to support other architectures.
I am just wondering why does the OP-TEE module handle all the logic of EFI_SMM_VARIABLE_PROTOCOL. Wouldn't something like the EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL make more sense?
This protocol could also be used to implement CapsuleUpdate().
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
I have a MACCHIATObin. Would this also be usable for the testing?
Regards
Heinrich
[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