ARMv8 Exception Levels and TrustZone Integration in KVM Virtual Machines
The ARMv8 architecture introduces a sophisticated security model through its TrustZone technology, which partitions the system into Secure and Non-Secure worlds. This partitioning is crucial for isolating sensitive operations, such as cryptographic functions, from the rest of the system. However, when virtualization is introduced via a hypervisor like KVM (Kernel-based Virtual Machine), the interaction between the virtual machines (VMs) and the TrustZone becomes more complex. The core issue revolves around whether a VM running under KVM can switch the processor to the Secure state and execute TrustZone applications.
In ARMv8, the processor operates at different Exception Levels (ELs), each with its own privileges and responsibilities. EL3 is the highest privilege level, responsible for managing the Secure Monitor, which handles transitions between the Secure and Non-Secure worlds. EL2 is the hypervisor level, where KVM operates, managing multiple VMs. EL1 is typically the operating system level, and EL0 is the user application level. The challenge arises because KVM, running at EL2, does not have direct access to the Secure world, which is managed at EL3. This creates a scenario where a VM, running at EL1 or EL0, cannot directly switch to the Secure state without the intervention of the hypervisor or the Secure Monitor.
The primary concern is whether a VM can execute TrustZone applications, such as WPA2 authentication and other cryptographic functions, within the Secure world. This requires the VM to switch the processor to the Secure state, which is not straightforward due to the separation of privileges between EL2 and EL3. The Secure Monitor, running at EL3, is the only entity that can facilitate this transition, but it is not directly accessible from a VM running under KVM.
Hypervisor Limitations and Secure Monitor Interaction
The inability of a VM to directly switch to the Secure state stems from the architectural design of ARMv8, which enforces strict privilege separation between Exception Levels. The hypervisor, running at EL2, is responsible for managing the VMs but does not have the necessary privileges to access the Secure world. This limitation is by design to ensure that the Secure world remains isolated from the Non-Secure world, including the hypervisor and the VMs it manages.
The Secure Monitor, running at EL3, is the gatekeeper for transitions between the Secure and Non-Secure worlds. It handles Secure Monitor Calls (SMCs), which are the mechanism for switching between these worlds. However, for a VM to issue an SMC, it must first pass through the hypervisor, which runs at EL2. The hypervisor can intercept the SMC and either forward it to the Secure Monitor or handle it in some other way. This introduces a layer of indirection that complicates the process of switching to the Secure state from within a VM.
Furthermore, the hypervisor must be explicitly designed to support such interactions. If the hypervisor does not provide a mechanism for VMs to issue SMCs, then the VM will be unable to switch to the Secure state. This is a significant limitation for scenarios where sensitive operations need to be performed within the Secure world, such as cryptographic functions or secure boot processes.
Implementing Secure State Switching in KVM Virtual Machines
To enable a VM to switch to the Secure state and execute TrustZone applications, several steps must be taken. First, the hypervisor must be configured to allow VMs to issue SMCs. This involves modifying the hypervisor code to intercept SMCs from the VM and forward them to the Secure Monitor. The hypervisor must also ensure that the VM’s state is properly saved and restored during the transition to and from the Secure state.
Second, the Secure Monitor must be configured to handle SMCs from the hypervisor. This involves modifying the Secure Monitor code to recognize SMCs issued by the hypervisor on behalf of the VM and to properly handle the transition between the Secure and Non-Secure worlds. The Secure Monitor must also ensure that the VM’s state is properly isolated from other VMs and the hypervisor itself.
Third, the VM must be configured to issue SMCs to the Secure Monitor. This involves modifying the VM’s operating system to include a TrustZone driver that can issue SMCs and handle the responses from the Secure Monitor. The driver must be carefully designed to ensure that it does not expose sensitive information to the Non-Secure world.
Finally, the system must be thoroughly tested to ensure that the Secure state switching mechanism works as intended. This involves testing the hypervisor, the Secure Monitor, and the VM’s TrustZone driver to ensure that they all work together correctly. It also involves testing the system under various conditions to ensure that it remains secure and stable.
In conclusion, while it is technically possible for a VM running under KVM to switch to the Secure state and execute TrustZone applications, it requires significant modifications to the hypervisor, the Secure Monitor, and the VM’s operating system. These modifications must be carefully designed and thoroughly tested to ensure that they do not introduce security vulnerabilities or stability issues. The process is complex and requires a deep understanding of the ARMv8 architecture, TrustZone technology, and virtualization. However, with the right expertise and careful implementation, it is possible to achieve secure state switching in KVM virtual machines.
