So now there are two separate hypervisors in one device.
When running they have no direct dependencies on each other though they may offer very low-level services to each other such as memory pool transfer and a message passing channel.
In the devices we are interested in, these two hypervisors will need some form of communication stack such that an application in the normal world can make a request of a Trusted Application (TA) in the secure world.
There are already some enablers out there for this:
- The GlobalPlatform Client API already allows the normal world application to target a request to a specific TEE from a selection of TEE’s in a device.
- A normal hypervisor already can route messages between software in its guest OSes.
- From the point of view of communication (not management) one Hypervisor “just” has to consider the other hypervisor a guest OS.
It is worth noting that in some instances, the guest OS to guest OS connectivity may be restricted by the design. For example, you may find the locking of one normal world OS, so it is only associated to one specific trusted OS, but in general the above structure requires the two hypervisors to co-operate in the routing of messages.
Overall, given the new capabilities in the processors, the communication is something that can be solved by software design. However, the architecture is a bit more complicated than that in the real world, because there are a number of other components that allow a TEE (even a normal one) to claim to be “Trusted”.
A more realistic architecture view
Typically, there are a couple more critical components on an ARM system.