[U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache

[AKASHI Takahiro]

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
> >
>