From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Wed, 19 Jun 2019 16:07:38 +0900 Subject: [U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache In-Reply-To: References: <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: <20190619070737.GL6610@linaro.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Jun 19, 2019 at 08:24:50AM +0200, Heinrich Schuchardt wrote: > 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? I think so. > > > >> > >>>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. Yeah, but please note that EFI_SMM_VARIABLE_PROTOCOL is not part of UEFI specification. > 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? It provides only read/write interfaces *without* protection. As far as SetVariable API is concerned, you cannot compromise any authenticated variables unless you can sign a given variable with a trusted private key even if you can make a SMI call. -Takahiro Akashi > 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? I think the answer will depend on what (feature) you want to test. -Takahiro Akashi > 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 > > >