Heinrich,
On Tue, Jun 18, 2019 at 10:45:26PM +0200, Heinrich Schuchardt wrote:
On 6/18/19 12:34 PM, Ilias Apalodimas wrote:
Hi all,
[...]
I think one version of the functions serving at runtime and boottime is enough.
The cache should be used both at runtime and at boottime.
So do you mean that we should replace the existing "boottime" version of get/set_variable with my code (algorithm)?
This is a bit complicated work because we should be able to *udpate* UEFI variables at boottime, but my version of hsearch_runtime() is a stripped (and modified) version and doesn't support it.
Do we really need a multilevel hash table? I would not expect hundreds of variables.
Please don't change your point suddenly. Here we are discussing whether "The cache should be used both at runtime and at boottime" or not.
Heinrich, the idea here is to present a copy of the variables on the OS and totally disable RT variable updating from the OS. If someone wants to update UEFI variables, we can pack them to a Capsule (using FIT image format) and apply them on next reboot. Given the fact that UEFI variables are not updated that often, isn't this a viable option? If it is, then we need to keep the access separated (as Akashi-san suggests) allowing bootime to change the variables.
Making the existing hsearch_r() executable at UEFI runtime is, as I said before, quite painful.
You could start the cache implementation with a less complicated data structure like a linked list.
This is totally a different issue. I listed this issue in my cover letter.
Essentially I expect three modules working together:
UEFI API implementation <-> Cache <-> Persistence driver
I would suggest to put each of these into a separate file.
Both the API implementation and the Cache have to be available at Boottime and at Runtime. A first version of the persistence driver may only be working at boottime.
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.
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.
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.
StandaloneMmPkg seems to be the hardware independent part of the solution. Where will the hardware driver reside in your OP-TEE solution?
Is the EDK2 hardware store for variables of the MACCHIATObin here: edk2-platforms/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c?
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.
Thanks, -Takahiro Akashi
Best regards
Heinrich
In case of write you could do a write-through in your cache if needed.
The NV-cache content should be written to non-volatile memory on Reset() and on ExitBootServices() and if possible when updating variables at runtime.
I'm not sure your intent here, but are you going to write back the cache only once? It won't work as every change of UEFI variable must be flushed to persistent storage instantly.
Thanks /Ilias