Visible to Intel only — GUID: nda1487649343034
Ixiasoft
Visible to Intel only — GUID: nda1487649343034
Ixiasoft
6.2.8.1.1. System Interconnect Firewalls and Slave Security
To change the security state of a slave requires a secure write to the appropriate SCR.
Firewalls check the secure bit of a transaction against the secure state of the slave. A transaction that passes the Firewall proceeds normally to the slave. A transaction that fails the Firewall results an error response with data set to 0. Transactions that fail the firewall are never presented to the slave interface.
The SCRs, implemented in the system interconnect, control the security state of each slave. The SCR is an internal target on the system interconnect, accessed through the service network. You can configure the slave security state on a per-master basis. This means that the SCR associated with each slave contains multiple secure state bits, one for each master allowed to access it.
Firewalls work in the following order:
- Based on the transaction's destination slave, fetch the entire slave SCR.
- Based on the transaction's originating master, read the master-specific secure bit in the SCR.
- Compare the secure bit with the transaction's secure attribute to determine if the transaction should pass the firewall.
The table below shows how the secure state of a slave is used with the transaction security bit to determine if a transaction passes or fails.
Transaction Security Bit | Slave Security State (SCR) | Result |
---|---|---|
0–Non-Secure | 0–Secure | Fail: simulate successful response |
1–Secure | 0–Secure | Pass: transaction sent to target |
0–Non-Secure | 1–Non-Secure | Pass: transaction sent to target |
1–Secure | 1–Non-Secure | Pass: transaction sent to target |