What Is Partition Checker in Arm Secure Mode

What is partition checker in ARM Secure Mode

What is the partition checker?

It is outside of the TrustZone specification for the CPU. However, in a nut shell it partitions or divided memory spaces into different permitted accesses. If the access is not permitted, it throws an external BUS error.

Is it a subsystem which has registers, what is its programming model?

Typically, it is a bunch of registers. It maybe multiple register files. For instance, an APB (peripheral bus), AHB (older ARM bus) and a new AXI (TrustZone aware bus) may all be present in one system. There may even be multiple APB buses, etc.

From the same page,

The principle of TrustZone memory management is to partition the physical memory into Secure and Non-secure regions.

It should be added that partitioning the masters as secure and non-secure is also important. The partitioning is outside the ARM CPU TrustZone specification; it is part of the BUS architecture. It is up to a bus controller/structure to implement this. The bus controller has both masters (CPUs, DMA peripherals, etc) and slaves (memory devices, register interfaces, etc) connected.

Partitioning in the context of the ARM TrustZone document is a little nebulous as it is up to each SOC and the bus controllers (and hierarchy) to implement the details. As above, it partitions or divided memory spaces into different permitted accesses. This is just like supervisor versus user access with traditional ARM (AMABA) AHB buses. The AXI interface adds an NS bit.

Here are possible combinations for a bus controller to support.

             |  Read  | Write 
-------------+--------+-------
Normal User  | yes/no | yes/no
Normal Super | yes/no | yes/no
Secure User  | yes/no | yes/no 
Secure Super | yes/no | yes/no

The SCR NS bit will dynamically determine whether the 'NS' bit is set on bus accesses. This is a TrustZone difference. For the super and user, there is a traditional HPROT bit. As well, each master will assert a WRITE/~READ signal (maybe the polarity is different, but we are software not hardware).

A DMA master (Ethernet, USB, etc) may also send out requests to a BUS. Typically, these are setup and locked at boot time. If your secure world uses the Ethernet, then it is probably a secure DMA master to access secure memory. The Ethernet chip also typically has a slave register interface. It must be marked (or partitioned) as secure. If the normal world accesses the ethernet register file, then an BUS error is thrown. A vendor may also make DMA peripherals that dynamically set the NS bit depending on the command structure. The CAAM is a crypto driver that can setup job descriptions to handle both normal and secure access, as an example of a DMA master which does both.

A CPU (say Cortex-M4 or Cortex-R) may also be globally secure or normal. Only the Cortex-A series (and ARMv6) with full TrustZone will dynamically toggle the NS bit allowing the CPU to be both secure and normal, depending on context.

Slave peripherals maybe partitioned. For example, the first 10MB of SDRAM maybe both normal and secure read and write for inter-world communication. Then next 54MB, maybe normal only read/write for the normal world. Then a final 64MB of read/write secure for the secure world. Typically, register interfaces for peripherals are an all or none setup.

These are all outside of the scope of an MMU and deal only with physical addresses. If the SOC locks them after boot, it is impossible for anyone to change the mapping. If the secure world code is read-only, it maybe more difficult to engineer an exploit.

Typically, all APB buses are layered on an AHB bus, which connects to an AXI main bus like a tree. The AXI bus is the default for a Cortex-A. Each BUS will have a list of slaves and masters and will support various yes and no configurations, which maybe a subset of the list above; Ie, it may not care about read/write or super/user or some other permutations. It will be different for each ARM system. In some cases, a vendor may not even support it. In this case, it maybe more difficult to make the system secure or even use TrustZone. See: Handling ARM TrustZones‌​, where some of the bus issues are touched on in less details.

See: TrustZone versus Hypervisor which gives some more details.

Control access to TZASC

TZASC register access is also 'on the bus'. Typical ARM TrustZone solutions have two type of access control. One for memory devices and another for device mapped memory. The TZASC register set is a device. So, the access control to it will be through the 'device mapped memory' control. For example on Freescale/NXP iMx product this is controlled by the CSU.

Locking the TZASC during secure boot insures that the mapping can not change. If you need a dynamic mapping then you have the flexiblity to use whatever the device memory control support. This is different for every ARM Soc.

Related

• What is partition checker in ARM Secure Mode
• ARM TrustZone, connecting peripherals?

TrustZone versus Hypervisor

A typical Hypervisor is limited to the CPU only. It does not protect against other DMA masters. See the Wikipedia DMA Attack web page for more on this. Other attack, such as a Cold boot, need other mechanism such as zeroizable memory to prevent exploitation. That is TrustZone is not a total security solution, but a big part of it. As the ARM is only a CPU, the mechanism to control the other BUS Masters is unspecified. Besides DMA Masters, alternate CPUs also pose a threat to memory partitioning. To address this, some secondary CPUs are TrustZone aware. Ie, they will always tag transactions with an NS bit (the 33^rd bit).

In contrast, a Hypervisor is rarely limited to two worlds. Hypervisors host any number of OS's. TrustZone only has two worlds; secure and normal. Although each world can have a controlling supervisor OS, with many separate threads, tasks, or processes as the OS permits.

DMA Attack explanation: In contrast to a hardware bit, a Hypervisor usually uses the CPUs MMU to limit software access. This doesn't prevent alternative BUS Masters from getting at the memory. If Hypervisor restricted software can control a separate BUS masters, then they can grab memory that is to be protected. DMA uses physical addresses and by passes the MMU and so general Hypervisor protection.

The DMA Attack circumvents CPU protection by using something outside the CPU to access memory. With TrustZone, the protection is NOT in the CPU, but in the BUS controller.^{See: NIC301 for a sample} An ARM TrustZone CPU just allows the CPU to support four modes; secure supervisor, secure user, normal supervisor and normal user. An normal ARM CPU only supports user and supervisor separation with all hosted OS's of a hypervisor running in user mode; typically all DMA peripherals run with supervisor privileged and the value is often hard-coded in the SOC.

---

Update: The original question did not include IOMMU.

---