4

For example, virt-what shows if you are running inside hardware virtualization "sandbox".

How to detect if you are running in ARM "TrustZone" sandbox?

Vi.
  • 37,014
  • 18
  • 93
  • 148
  • Do you want to tag this with [tag:linux] or [tag:linux-kernel]? Now it looks like an ARM CPU system code question. You may get different info depending (or at least more comprehension)? – artless noise Jan 20 '14 at 23:47
  • TrustZone is less like virtualization and more like SMM, if an x86 analogy helps. If you're running Linux at all (except on certain developer boards and the boot loader has not switched states for you), you are executing in Non-secure state. – unixsmurf Jan 21 '14 at 05:24

3 Answers3

4

TrustZone maybe different than what you think. There is a continuum of modes. From 'a simple API of trusted functions' to 'dual OSs' running in each world.

If there was more context given to the question, it would be helpful. Is this for programatically determining or for reverse engineering considerations? For the current Linux user-space, the answer is no.

Summary

  • No current user space utility.
  • Time based analysis.
  • Code based analysis.
  • CPU exclusion and SCR.
  • ID_PRF1 bits [7:4].

virt-what is not a fool-proof way of discovering if you are running under a hyper-visor. It is a program written for linux user-space. Mostly, these are shell scripts which examine /proc/cpuinfo, etc. procfs is a pseudo-file system which runs code in the kernel context and reports to user space. There is no such detection of TrustZone in the main line ARM linux. By design, ARM has made it difficult to detect. An design intent is to have code in the normal world run unmodified.

Code analysis

In order to talk to the secure world, the normal world needs SMC instructions. If your user space has access to kernel code or the vmlinux image, you can try to analyze the code sections for an SMC instruction. However, this code maybe present in the image, but never active. At least this says whether the Linux kernel has some support for TrustZone. You could write a kernel module which would trap any execution of an SMC instruction, but there are probably better solutions.

Timing analysis

If an OS is running in the secure world, some time analysis would show that some CPU cycles have been stolen if frequency scaling is not active. I think this is not an answer in the spirit of the original question. This relies on knowing that the secure world is a full-blown OS with a timer (or at least pre-emptible interrupts).

CPU exclusion and SCR

The SCR (Secure configuration register) is not available in the normal world. From the ARM Cortex-A5 MPcore manual (pg4-46),

Usage constraints The SCR is:
• only accessible in privileged modes
• only accessible in Secure state.
An attempt to access the SCR from any state other than secure privileged results in an Undefined instruction exception.

ID_PRF1 bits [7:4].

On some Cortex-A series, the instruction,

mrc p15, 0, r0, c0, c1, 1

will get a value where bits [7:4] indicate whether the CPU supports Security Extensions, also known as TrustZone. A non-zero value indicates it is supported. Many early CPUs may not support this CP15 register . So, it is much like the SCR and handling the undefined instruction. Also, it doesn't tell you that code is active in the TrustZone mode.

Summary

It is possible that you could write a kernel module which would try this instruction and handle the undefined exception. This would detect a normal versus secure world. However, you would have to exclude CPUs which don't have TrustZone at all.

If the device is not an ARMv6 or better, then TrustZone is impossible. A great deal of Cortex-A devices have TrustZone in the CPU, but it is not active.

The combined SMC test and a CPU id, is still not sufficient. Some boot loaders run in the secure world and then transition to the normal world. So secure is only active during boot.

Theoretically, it is possible to know, especially with more knowledge of the system. There maybe many signs, such as spurious interrupts from the GIC, etc. However, I don't believe that any user space linux tool exists as of Jan 2014. This is a typical war of escalation between virus/rootkit writers and malware detection software.TZ Rootkits

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • "A great deal of Cortex-A devices have TrustZone in the CPU, but it is not active." -> Is it _securely_ not active or there can be some vendor-installed spyware running in "non-active" TrustZone scanning for signatures and allowing sudden code execution? Does cheap SoC boards like Raspberry Pi or Cubieboard usually allow installing of my own bootloader taking advantage of secure mode (to protect my own data with my programs) or there's some hidden treacherous "pre-bootloader" just to [reduce functionality of my device](https://en.wikipedia.org/wiki/Crippleware) (if not worse)? – Vi. Jan 21 '14 at 14:13
  • If an ARM CPU has *TrustZone*, it means some **hardware** is there; you still need additional hardware to make it useful. Even when all the hardware is present, you still need a 'driver' (meaning software to enable that mode). See [trustzone whitepaper](http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf) (registration maybe required?). I believe some vendors make the SOC ROM bootloader go to *normal world*, so that these chips can not *dupe* the secure customers. *Secure boot* is needed for TrustZone to be meaningful. – artless noise Jan 21 '14 at 15:22
1

You have not specified any details of the processor (A8, A9, A15?) or the execution mode (user/kernel/monitor) from where you want to detect the processor state.

As per the ARM documentation, the current state of the processor as Secure (aka the TrustZone sandbox) or Non-secure can be detected by reading the Secure Configuration Register and checking for the NS bit.

To access the Secure Configuration Register: MRC p15, 0, <Rd>, c1, c1, 0 Bit 0 being set corresponds to the processor being in non-secure mode and vice-versa.

vPraetor
  • 313
  • 1
  • 3
  • 13
  • Should it be accessible only from OS kernel or from any process? – Vi. Jan 19 '14 at 19:42
  • AFAIK none of the co-processor registers are accessible from userspace. You should try it from within the kernel. – vPraetor Jan 20 '14 at 18:52
  • Secure Configuration Register is also not accessible from Normal-mode kernel, and will trigger an undefined instruction exception. However, this is also the only portable method of finding out. – unixsmurf Jan 21 '14 at 05:19
  • 2
    @artlessnoise: I read the question very differently - it is about checking where you are currently executing your code. The fault tells you that you are not in a Secure mode. Anyway, there is no way to determine from a Non-secure execution mode that something is pre-empting you and executing in Secure world other than time disappearing. – unixsmurf Jan 25 '14 at 13:40
0

You can check the processor's datasheet, and find those registers which behaves different between Normal world and Secure world. Generally, in Secure World, when you read these registers you will just get null. But get data in Normal world. And also, some registers that you can just access in Secure world, if you are in Secure World, you can access it, but in Normal World your access will be rejected.

Any way, there are many ways to distinguish Normal World and Secure World. JUST READ THE DATASHEET IN DETAIL.

Cobain
  • 186
  • 1
  • 8