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