From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Wed, 19 Jun 2019 08:24:50 +0200 Subject: [U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache In-Reply-To: <20190619051333.GA28481@apalos> References: <20190605042142.15113-1-takahiro.akashi@linaro.org> <20190605042142.15113-7-takahiro.akashi@linaro.org> <9501311b-4f36-5ffb-8daf-cccea00684d0@gmx.de> <20190617015145.GC6610@linaro.org> <0aa22f8a-b391-ace3-76db-c2b223e96f6c@gmx.de> <20190618011903.GF6610@linaro.org> <20190618103448.GA25137@apalos> <51b0ca13-c028-8469-cd97-7674f5825ac4@gmx.de> <20190619012506.GK6610@linaro.org> <20190619051333.GA28481@apalos> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >