Hi Jens,
Jens Wiklander writes:
Hi Volodymyr,
[...]
As you can see, client TEE instance writes the request to a shared buffer inside the secure memory. Then it issues RPC request back to own supplicant. Supplicant uses hypervisor-provided way to signal frontend server in the DomD. In case of Xen, inter-domain events can be used. This is a common mechanism to implement PV drivers in the Xen. Virtio also provides similar methods of signaling. PV server in DomD opens session to pTA in OP-TEE that belongs to DomD. This pTA accesses the previously written shared memory and reads the request from DomU. Then it can handle request - i.e. issue RPMB command. This provides the secure way to transmit requests from one TEE instance to another without adding inter-domain locking mechanisms. Obviously the same mechanism can be used not only for RPMB requests but for any inter-domain communication.
It looks like this approach will work with SPCI also.
Ah, SPCI... Yes, this should be work with SPCI and nothing else is not needed if SPCI is present. But last version of SPCI spec I saw didn't supported dynamic agent allocation. Only static configuration. This could be fine in embedded use-cases, but would not work for servers.
Partitioning RPMB Area
The provided mechanism answers the question “how to access RPMB from multiple domains”. But there is another question: “how to share space on RPMB partition?”. Now OP-TEE have a static number of domains configured at a compilation time (``CFG_VIRT_GUEST_COUNT`` configuration option). So, we can divide RPMB partition into ``CFG_VIRT_GUEST_COUNT`` (equal) parts and grant every guest access to one of these. But how we can make sure that guest A will have access to partition for guest A, not for guest B? We can’t rely on VM ID received by hypervisor at least because VMs can be restarted and each time it will get a new ID. Also, IDs will vary depending on VM creation order. Clearly we need persistent Virtual Machine ID (GUID will be fine). But I can’t see a way how TEE instance can be sure that it communicates with the same VM every boot. As hypervisor could swap GUIDs between “good” and “rouge” VMs.
Installed TAs has to be tied to the secure storage solution and in the end the RPMB partition. We're using such a bond if we're only using TAs registered, either as early TAs or in the TADB in secure storage. With that the problem is reduced to a rouge hypervisor being able to connect a VM to wrong TEE instance. Secure world cannot trust normal world any way so this shouldn't be a problem from secure world point of view, a disaster in normal world but that is already lost if the hypervisor can't be trusted.
Yes, I have come to the same conclusions. Looks like we just should cope with this if we want to use virtualization.
Anyways, we also considering secure boot for NW. This should decrease chances of problems with a Normal World.
[...]
Extending TEE virtualization API
With features above, we need to extend virtualization-related APIs. The ``OPTEE_SMC_VM_CREATED`` call should be extended with the following information:
GUID of the virtual machine
Flag to indicate that this machine have access to real RPMB partition
In the future number of flags can be extended to denote ability to access hardware accelerators for example.
Also we need pTA for RPMB partition table management. So hypervisor (or trusted domain) can configure the table, e.g. - to assign GUIDs to table entries. It is debatable if it also should be able to wipe out partitions to re-assign GUIDs later.
In some special management mode I guess anything should be possible. I'm not sure it makes sense to allow the creation of new partitions unless you're in this special management mode since the created TEE need to be configured with keys etc specific to this instance.
Probably, that could be the same mode, where RPMB key programming is enabled.
Per-TEE keys is another interesting topic. I believe, they can be derived from VM GUID and HUK. What do you think?
Comparison of proposed approaches
Comparison is made in form of table. Please see it in the PDF version at https://urldefense.com/v3/__https://xen-troops.github.io/papers/optee-virt-r...
Depending on hardware configuration it seems there's always at least one good option, but not a single generic solution that works for all. So "Sharing using OP-TEE" option is really useful as a complement to the other options.
Yep. I believe that we can start with this. That would require to implement inter-TEE communication interface, but we would need it anyways - for another HW-related interactions.
P.S. sorry for that urldefense.com-mangled links. Our mail server is paranoid a bit.
-- Volodymyr Babchuk at EPAM