4

Context

I want to have a rich GNU/Linux OS running in the Normal world and a small OS with an integrated Monitor running in the Secure world.

Requirement

We have to absolutely avoid the Normal world to access the Secure world memory region.

Question

Which feature(s) of TrustZone do we need to use/activate to fulfill this requirement? I'd like to use only the necessary features to minimize the work needed.

Details

I've read quite a lot of ARM TrustZone documentation, I'm aware of TZPC, TZASC, MMU with security extensions, but I can't figure out how to avoid the following threat:

What would stop a hacker, once he gained access to the kernel space, to deactivate the MMU, and directly access the physical memory region of the Secure world?

Maybe this is not even imaginable or feasible? But if it's the case, my guess it that a TZPC is mandatory to prevent this, am I right? Or, does "simply" using the two TrustZone worlds is enough?

cid
  • 696
  • 1
  • 8
  • 19

2 Answers2

2

What would stop a hacker, once he gained access to the kernel space, to deactivate the MMU, and directly access the physical memory region of the Secure world?

The MMU is not involved with TrustZone at all. So disabling the MMU accomplishes nothing. Possible attacks are against the monitor code, the secure OS API (to the normal world), bus protection, boot code or hardware. The MMU with security extensions is to allow secure world code to access memory as per the normal world and fault accordingly.

Similar to a rogue normal world kernel disabling the MMU, a DMA attack can also be used on a traditional hypervisor. TrustZone purpose is to avoid these attacks.

The TZASC is one way for secure boot code to lock the hardware. You could think of it as partitioning the hardware between secure and normal with possibilities for read/write access.

              | read  | write
 -------------+------------------
 normal super | Y/N   | Y/N
 normal user  | Y/N   | Y/N
 -------------+------------------
 secure super | Y/N   | Y/N
 secure user  | Y/N   | Y/N

The first two lines are in all ARM systems. The last two are specific to TrustZone. Physically, these are signals on the bus. The bits are Read/Write, secure/normal (NS tag bit) and super/user. Each BUS master will be statically assigned to a world or if the master is TrustZone aware, it may be dynamic. One dynamic master example is a CPU. For slaves, they are either memory (large array of similar I/O) or small controller register banks. For the memory, the TZASC allows partitioning of the memory. For smaller register slaves, a simpler all or nothing bus access is usually implemented (TZPC for example). TrustZone is very vague to a system programmer because it is flexible to allow different SOC designs.

Maybe this is not even imaginable or feasible? But if it's the case, my guess it that a TZPC is mandatory to prevent this, am I right? Or, does "simply" using the two TrustZone worlds is enough?

TZPC is an example of simple slave secure/normal partitioning. For register based I/O on a AMBA APB (advanced peripheral bus).

[This section is meant as a concrete example of the flexibility of the TrustZone architecture in letting SOC implementers create novel devices that maybe useful for some particular applications.]

Consider a system where we have one NAND chip (NFC) but want to allow both secure and normal access with normal world unable to access secure data. If we create a TrustZone aware NFC controller we can have two banks of I/O registers and DMA data to user specified buffers. One register bank is secure, the other normal. The NFC controller would be a secure master and the NFC chip would be a secure slave. When someone accesses the NFC controller normal register bank the hypothetical chip must check that the access is allowed (that would be hardware in the attacks above) and another example of a dynamic master. When it read on behalf of the normal world, it would DMA with NS set so that the normal world access permissions would apply.

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • I may not be understanding well but how is this answering my question? It is then mandatory to protect the physical memory regions of the secure world using TZASC/TZPC? – cid Sep 09 '15 at 19:44
  • The TZASC and TZPC are one way (like there are different ethernet controllers, but they all do 'ethernet' protocol). Semantically, these elements control BUS access; they are outside a CPU. You didn't mention the [Exynox 4210](http://www.samsung.com/global/business/semiconductor/file/product/Pulbicmanual_Exynos_4_Dual_45nm_Ver00-2.pdf). Sec 2.2 of the manual has hints (things with a 'dash' might be under NDA/security disclosure). TZPC 0-6 are also there. It is possible they control memory but that it is a little odd. You need to put your vendor (Samsung) documents with ARMs. – artless noise Sep 10 '15 at 14:17
  • Nothing is **mandatory**. Security solutions are not a one-stop issue. [Different assets/situations are present in every different product](http://www.cl.cam.ac.uk/~rja14/book.html). TrustZone gives some tools to help with this. What you do in your design is up to you (and your SOC vendor, Samsung). Every ARM Cortex-A CPU has TZ support. If the vendor doesn't protect the BUS, then it is useless for most situations. You need to be in close discussions with the vendor or their agents (VARs, etc). You also need tampers, etc to mitigate hardware hacks that manipulate memory directly. – artless noise Sep 10 '15 at 14:23
  • (... **may** need tampers). This [ARM bus question](http://stackoverflow.com/questions/28068525/can-you-help-me-understand-peripherals-addressing-and-bus-architecture-in-arm-ba) might be helpful. The SOC vendor implement the BUS for TrustZone to be complete (for most situations) the vendor has to give some secure/normal access. The access could be static (hard coded), dynamically configured all or nothing (as the TZPC) or dynamic partitionable as a TZASC. – artless noise Sep 10 '15 at 14:34
1

The untrusted code is running in non-secure state, therefore any bus transactions generated by the CPU will be marked as non-secure, thus it's the inherent functionality of the interconnect that keeps things separate. The secure memory map and the non-secure memory map are actually entirely separate things, it's just that in most systems they are wired up to be more or less identical.

Now, that "secure world memory" is either going to be some dedicated block (usually on-chip SRAM) that is hard-wired to the secure memory map, or a chunk of general DRAM carved out and made secure-only via a TZPC/TZASC. Either way, it simply doesn't exist in the non-secure memory map, therefore there's nothing non-secure software can do to access it.

Notlikethat
  • 20,095
  • 3
  • 40
  • 77
  • But what if the actual SoC don't implement TZASC/TZPC? – cid Sep 09 '15 at 19:46
  • Well then you'd either have hard-wired secure, non-secure and shared memory, or the thing is simply not designed to support secure software so you give up and go home. – Notlikethat Sep 09 '15 at 19:59
  • Ok, but then what is the purpose of supporting TZ but possibly w/o TZPC or TZASC? I'm working with a Exynos 4210. While supporting TZ, the manual is only mentioning TZPC in the memory map. Nothing more, so I don't really know if I should "go home". – cid Sep 09 '15 at 20:09
  • 1
    If you have a TZPC, then you're going to have some memory behind it which you can partition off a secure chunk of. I'm not familiar with Exynos 4, but I did once play with an Exynos 5410 and I know the secure firmware there sets things up so the on-chip SRAM (which it calls iRAM) is split between the secure firmware and the non-secure bootloader entry point. And also that Samsung's publicly-available TRMs contain almost no useful information whatsoever. Incidentally, the ROM code that bootstraps loading that firmware is a good example of something hard-wired to the secure world. – Notlikethat Sep 09 '15 at 20:35