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

[Heinrich Schuchardt]

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
>