|Home > Operation > Security|
The GIC-600 supports the Arm TrustZone® technology. Each INTID must be assigned a group and security setting.
The GIC-600 supports the three interrupt groups that are shown in the following table.
Table 3-1 Security and groupings
|Interrupt type||Example use|
|Secure Group 0||Interrupts for EL3 (Secure firmware)|
|Secure Group 1||Interrupts for Secure EL1 (Trusted OS)|
|Non-secure Group 1||Interrupts for the Non-secure state (OS and the Hypervisor, or one of both)|
The following table shows the interrupt signals that are used for each interrupt group, Security state, and Exception level.
Table 3-2 Interrupt signals, Security states, and Exception levels
|Core Exception level and Security state||Group 0||Group 1|
|Secure EL0, EL1||FIQ||IRQ||FIQ|
|Non-secure EL0, EL1, EL2||FIQ||FIQ||IRQ|
Setting the Disable Security (DS) bit to 1 in the GICD_CTLR register removes the security support of the GIC-600. It can be set by Secure software during the boot sequence or configured to be always set when you configure the design using the parameter ds_value. When the system has no concept of security, you must set GICD_CTLR.DS to allow access to important registers.
If you set GICD_CTLR.DS to 1, only a single Security state is supported. In a single Security state, register access, and the behavior and number of interrupt groups supported are affected. For more information, see Interrupt grouping, and Interrupt grouping and security in the Arm® Generic Interrupt Controller Architecture Specification, GIC architecture version 3.0 and version 4.0.
If you run software without security awareness on a system that supports security, the Secure boot code can set DS before switching to a Non-secure Exception level to run the software. This enables you to program the GIC-600 from any Exception level and use two interrupt groups, Group 0 and Group 1, so that interrupts can target both the FIQ and IRQ handlers on a core.
Group 0 is always Secure in systems with security. If you decide to write security-unaware software using Group 0, it might not be portable to systems with a concept of security. Security-unaware software is most portable when written using Group 1.
If a system has a concept of security but one or more cores do not, then you must not set DS. Instead each core is only able to enable the interrupt groups corresponding to the Security states that it supports.
In security aware systems, Secure software can prevent the DS bit from being written by writing to Disable Security Lock bit (GICD_SAC.DSL). When set, only a hardware reset can clear the DSL bit.
If you know that your system is always security aware, then Arm recommends configuring the GIC-600 without DS support.