This article is a follow on from the previous postings:
and you might find those useful as first reads if you are unfamiliar with TEE technology.
What are Hypervisors?
Hypervisors enable multiple OSes (or other things) to run in a common area of devices such as smartphones, engine management units and large Internet Of things (IOT) devices.
Simplistically
- An application (App) has an Operating System (OS) providing services, execution time, and isolation from other Apps,
- In a Hypervisor system the OS has the Hypervisor providing services, execution time, and isolation from other OSes (and their Apps).
The diagram is showing one arrangement of the components. There will be others.
In a device like a smartphone, one of the OSes is typically the one the user directly interacts with (such as Android OS), the others may be doing something like the modem functionality that helps connect a smartphone to the mobile network.
As an additional benefit, the goal of “simple as possible” pushes hypervisors to move anything un-necessary for their basic isolation task into a special Guest OS which is just there to serve the Hypervisor (for the generic hypervisors this is called Dom0 after Domain Zero – the first “guest” domain established by the Hypervisor after boot). This simplification of the lowest level critical functionality is also done by micro-kernel based Trusted OSes like Trustonic’s Kinibi where anything un-necessary for the basic isolation task is moved into the user space.
Why use Hypervisors?
Why do designers add hypervisors?
- Firstly, they allow incompatible functionality requirements to be supported inside a device. Consider a classic PC running both Windows ™ and Linux ™ using a form of Hypervisor to separate these conflicting capabilities.
- Secondly, due to that strong isolation, they allow the developer to add new functionality without risking breaking old functionality. You may be amazed at the amount of code that exists today that no one can maintain but is essential to the operation of devices. The solution to this risk is to add a hypervisor, put the old software in as one “Guest” and the new software in as another.
- Thirdly, it separates domains of trust. If you trust the hypervisor and its claims of ability to create isolation, then you can execute code in one hypervisor domain without having to trust the code in any of the other hypervisor domains.
TEE alongside the Hypervisor
In the past a Trusted Execution Environment (TEE) was either a separate security subsystem, or if it used some isolation technique such as the ARM TrustZone technology, it was a clever piece of SoC separation based on the security state of the data transfers going on in the SoC (and yes code is just a special case of data).
With a traditional TEE the simplistic devices internals then looked like:
Hypervisors provide strong isolation between their Guest Domains and, like a Trusted OS in a TEE, they are not overloaded with functionality. In the Hypervisor case just enough to enable the Guest OSes.
Hypervisors inside the Trusted Execution Environment (TEE)
In the last few years a number of technologies have pushed the Hypervisor concept in the embedded space from both ARM and the RISC-V foundation.
Both of these (in the correct hardware design) have the potential to place multiple stakeholders in the Secure World.
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.
Hypervisor Support Code:
As shown earlier, a good hypervisor will have its support code in a domain and not part of its most privileged code block. Don’t forget we have two independent hypervisors, and each has its own dedicated support code.
Monitor Mode:
This is a piece of code that manages the actual switching of state in the cores from normal world to secure world. Effectively it is also a very simple Hypervisor though the “MMU” it uses is actually the TrustZone Technology. This TrustZone technology has some distinct difference compared to traditional MMUs. It only supports two guests and it has some innate access control rules built into the hardware. It can also be designed to not actually allow software to make run-time changes to the isolation barriers. Additionally, TrustZone Technology also “firewalls” the data separation at more SoC Locations than the normal MMU.
SW Boot code:
This is the first code to run on a core and it sets up the initial state of the secure world.
What is a TEE in this brave new world?
A Trusted Execution Environment (TEE) should be considered as a stack of components that a Trusted Application is having to trust to provide the required functionality and isolation.
For the first TEE it is…
For the second TEE it is…
…And there can be more TEE’s if the device has the resources.
As you can see the Secure World Boot Code, monitor mode Code, and the Hypervisor code are common to all the TEE’s.
For a security validation of a particular TEE all these components have to be included. This is interesting as for many years there has been an ongoing drive to enable composite security evaluations, where the manufacturer of each component can get an evaluation and then the manufacturer of the composite of all those components can get a faster evaluation enable those component evaluations. As you can see, this is concept is a useful enabler in the above structure.
Why a Hypervisor for the Secure World?
In the ideal secure world, all those who used the TEE would trust the TEE to provide the isolation and functionality that they needed.
Today there is a conflict in device TEE designs between:
- The OEM who wants to use the secure world for special features and security,
and
- The OEM who wants to ship their product as quickly as possible and doesn’t want to spend as much effort as they might on developing security functionality in critical components (such as drivers). This team in the OEM want to port drivers written without security to speed the process and put them in the TEE.
and
The external company who wants their bank card, or Manchester City season ticket, or help you store your favourite cat photos, in the most secure space on the phone.
and
- A good TEE is minimalistic.
- More code brings more security risk.
- However, there are competing factors continually pushing for more functionality that isn’t required by some applications but is by others. Functionality like TUI, NFC readers, SE interfaces, sockets layers. A Hypervisor is one way to allow for the same device to have multiple TEE’s with different functionality tuned to the various needs.
A secure Hypervisor supporting a range of TEE’s can enable all these use cases and remove the related design conflicts.
Conclusions
Hypervisors add more code to the Trusted Execution Environment (TEE) which can reasonably be considered a bad thing, but a good hypervisor is minimalistic and effectively the ARM TrustZone already has one layer of Hypervisor built in to move the core from Normal World to Secure World.
The addition of hypervisor support, enabling multiple Trusted OSes should reduce overall security risk by reducing the trend of a TEE to drift towards containing more of a feature rich OS capability set, and allow different TEE needs to sit side by side with minimal interference.
In the future, a good multi TEE environment may look like….
