AXI Permissions

Memory and Peripheral Protection Unit for PL Isolation in Zynq UltraScale+ Devices (XAPP1353)

Document ID
Release Date
v1.1 English

The AxProt[2:0] (ARPROT and AWPROT, collectively) holds the permission levels for the AXI transaction. AxProt[0] indicates the Privilege level, AxProt[1] indicates Security level, and AxProt[2] indicates whether it's an instruction or data type transaction. The definitions and values are shown in Table 1.

ARPROT:	Read Transaction Permissions
AWPROT:	Write Transaction Permissions
Table 1. AXI Protection Permissions
AxPROT[2:0] AXI Protection Level
000 Data Access, Secure, Unprivileged
001 Data Access, Secure, Privileged
010 Data Access, Non-secure, Unprivileged
011 Data Access, Non-secure, Privileged
100 Instruction Access, Secure, Unprivileged
101 Instruction Access, Secure, Privileged
110 Instruction Access, Non-secure, Unprivileged
111 Instruction Access, Non-secure, Privileged

AxProt[1]holds the security level for the AXI transaction. In the Processing System (PS), the TrustZone (TZ) setting for an AXI master is transferred over the AXI3 infrastructure using AxUser[10], but this information is not transferred to the AXI4 PL interfaces. Unfortunately, AxProt[1] does not directly reflect the TZ setting for all masters.

PS masters having a TZ NONSECURE register setting, such as DMAs, use AxProt[1] to communicate the AXI Permission security level in accordance with its TZ setting. Therefore, regardless of whether isolation is enabled in the design, the DMA may be dynamically configured to make AXI transfers with either secure or non-secure AXI Permissions.

The APU sets AxProt bits in accordance with the exception level of the thread requesting the AXI transfer. Bare-metal standalone OS applications always execute at EL3 (AxProt[1]=0) which is AXI secure. Therefore, even if an APU application may be considered non-secure in the Isolated System, its AXI Permissions indicate it as it being secure. This is why you must use Master IDs to control region access authorization. However, APU applications running from a Linux kernel execute at EL0 (AxProt[1]=1) which is non-secure and may be elevated by the OS or hypervisor.

The RPU and PMU do not support multiple exception levels and always operate at EL3. Therefore, you must use the MasterIDs to block their access to a region.

Tip: Non-Secure Strict Check Type Regions will only allow transactions from authorized masters with a Non-Secure TZ setting, like DMAs, or with multiple exception level settings, such as a Linux app in the APU. Otherwise, simply define the region as secure and specify which masters should have access in the region configuration.