Does load/store-exclusive violate Hypervisor Transparency?

Hello Community,

I am currently learning hypervisor design using ARM's virtualization extensions (on both ARMv7 and ARMv8).

A note in the ARMv8-A reference manual (section D1.5) mentions:

"In some systems, a Guest OS is unaware that it is running on a virtual machine, and is unaware of any other Guest OS. In other systems, a hypervisor makes the Guest OS aware of these facts. The ARMv8-A architecture supports both of these models."

According to this, it should be possible to implement an entirely transparent hypervisor, e.g., one that is not detectable by software running inside a guest (maybe except from external timing). However, I do not understand how this can be true in the presence of the load/store-exclusive instructions.

As I understand, the local exclusive monitor must always be cleared on a context switch. This prevents a thread from inheriting exclusive monitor state from another thread. Consequently:

• Any ARMv7 hypervisor must issue a CLREX instruction before the ERET that performs the world switch. KVM/ARM does exactly that and I guess this is also true for Xen.
• In ARMv8, the ERET instruction implicitly clears the exclusive monitor.

Hence, every world switch back to a guest clears the exclusive monitor on both ARMv7 and ARMv8.

But this behavior makes hypervisors relying on the ARM virtualization extensions detectable. A detector could perform the following test:

1. Issue a LDREX. This sets the local monitor to "Exclusive Access" state.
2. Perform an instruction that generates no exception during normal execution but is trapped by the hypervisor.
   • When no hypervisor is present, no context switch occurs and the local monitor remains in "Excluive Access" state.
   • When a hypervisor is present, the world switch back to the guest clears the local monitor, setting it to "Open Access" state.
3. Issue a STREX. If it executes successfully, no hypervisor is present. If it fails, a hypervisor is present.

Step 2 might require privileged execution (e.g., in a kernel module). The detector might have to disable preemption or perform the test multiple times to be sure the local monitor was not cleared by another thread. However, it should be possible to detect any hypervisor that way.

There seem to be no mechanisms in ARM that would let the hypervisor circumvent this detection method (e.g., by emulation). That would mean, no hypervisor using the ARM virtualization extensions can be completely transparent (except for timing). This bugs me, because transparency is quite important for many security applications that use VMs (e.g., malware analysis). Am I missing something?

Thanks,

Jan