ARM TrustZone, Hypervisor: Hypervisor functionality WITHOUT Virtualization Extensions

1
votes

I have found some interesting information regarding CPU virtualization for ARM and I'm wondering if you guys could help me understand more about it.

Basically, folks at some company called SierraWare have developed an ARM secure-mode OS called SierraTEE that (they say) virtualizes a guest OS like Linux/Android running in non-secure mode, needing only the Security Extensions. A piece of information from one of their presentation documents has caught my attention, specifically at page 19 of this PDF http://www.sierraware.com/sierraware_tee_hypervisor_overview.pdf they state:

Integrity checks for Rootkits and Kernel Hacks:

  • Monitor Syscall interrupt and interrupt handler. This will ensure that core syscalls are not tampered with.

By "Syscall interrupt" I understand SVC (=old SWI) instruction executions (correct me if I'm wrong), but by "monitoring" I'm not really sure because it could be real-time monitoring, from-time-to-time monitoring or on certain-events monitoring. In my mind they could monitor the SVC handler to prevent tampering-with by either:

  1. Inspect SVC handler from time to time (timer interrupt for instance, since IRQs and FIQs can be routed to monitor mode) - PatchGuard-like approach, doesn't seem very useful to me
  2. Inspect SVC handler on SVC instruction execution (=certain-events monitoring)
  3. Trap SVC handlers memory region write-access (=real-time monitoring)

Regarding approach 2: would it be possible to trap non-secure SVC instruction executions from secure-mode?

Regarding approach 3: would it be possible to hook non-secure memory-region writes by using only the Security Extensions?

Thanks very much in advance

1
armvirtualizationhypervisortrust-zone
If you want a hypervisor, get a hypervisor. TrustZone would protect the secure OS, and provides no protection for the normal OS. Normally, a hypervisor must provide a virtual mmu to the hosted OS. TrustZone provides two physical MMU tables. Otherwise, SierraTEE has nothing to do with TrustZone. Protection should be done with a bus switch to prevent over-writes. Whatever the code is doing, it doesn't protect against an over-write of the checker in the secure mode. From secure mode, you may inspect the normal (Android OS) and see if it is tampered. - artless noise
1. is possible. 2. is impossible (without patching code or para-virtualization). 3. is also not possible without modifying Linux (para-virtualization). All approaches assume some knowledge of the hosted OS (Linux/Android). For instance, you can not run FIQ code such is used on some Linux IMX devices. Without secure boot, anyone may over ride the checker. - artless noise

1 Answers

0
votes

"Monitor" here may refer to the Monitor mode, the new mode added by the Security Extensions.

I'm not very familiar with the Security Extensions but I imagine it should be possible to mark specific memory regions as secure so any access to them will result in a Monitor mode trap, which can then handle the access and resume the non-secure code execution.

However, I just found this notice in the ARM ARM (B1.8.7 Summaries of asynchronous exception behavior):

In an implementation that includes the Security Extensions but does not include the Virtualization Extensions, the following configurations permit the Non-secure state to deny service to the Secure state. Therefore, ARM recommends that, wherever possible, these configurations are not used:

  • Setting SCR.IRQ to 1. With this configuration, Non-secure PL1 software can set CPSR.I to 1, denying the required routing of IRQs to Monitor mode.

  • Setting SCR.FW to 1 when SCR.FIQ is set to 1. With this configuration, Non-secure PL1 software can set CPSR.F to 1, denying the required routing of FIQs to Monitor mode.

The changes introduced by the Virtualization Extensions remove these possible denials of service.

So it would seem it's not possible to achieve perfect virtualization with just Security Extensions.