A chip holds the keys for its secure boot in a small block of memory. Ordinary software must never read them. The memory controller receives a read for that address. The read looks exactly like every other read: an address, a length, a request to return data. If that is all the request carries, the controller has nothing to decide with. It must answer, and the keys leak.
What must a request carry so that the target can decide whether to serve it?
The obvious answer is to protect memory in software: the operating system's page tables keep programs away from the keys. That protects only accesses that go through those page tables. A DMA engine, a debug port, a misconfigured accelerator or compromised privileged software can all issue requests directly onto the fabric. The fabric itself must know who is asking, and the only way to know is for every request to carry it.
Attribute | Says | Example |
|---|---|---|
Security state | Secure or non-secure world | AXI AxPROT[1] (non-secure bit) |
Privilege | Privileged (operating system) or unprivileged (application) | AXI AxPROT[0] |
Requester identity | Which agent issued it | AXI ID or master ID; PCIe Requester ID (bus, device, function) |
Address space | Which process or virtual machine's addresses these are | PCIe PASID; SMMU stream and substream IDs |
Access type | Read, write, instruction fetch | AXI AxPROT[2] (instruction) |
Set by hardware from true state: a processor's security bit comes from the security state it is executing in, not from software's choice. A requester that could set its own attributes could claim anything.
Carried unchanged: interconnects and bridges must preserve attributes. A bridge to a protocol without a security bit must map requests to a defined, conservative state (typically non-secure), never drop the distinction silently.
Assigned for agents that cannot be trusted: a DMA engine or a PCIe device gets its attributes and identity from the fabric port it is attached to, or from a translation unit (lesson 14.3), not from itself.
Checked at, or in front of, the target: by a firewall (lesson 14.2), a translation unit, or the target itself.
Protocol | Attributes |
|---|---|
AMBA AXI | AxPROT: privileged, non-secure, instruction; AxID identifies the transaction source; TrustZone security rests on the non-secure bit (facts A23, A27). |
PCI Express | Requester ID (bus, device, function) in every request; PASID for the address space; virtual functions give each virtual machine its own ID (fact P35). |
Simple peripheral buses | Often none: protection must be added in front of them |
A chip (illustrative) connected a legacy DMA controller through a bridge that had no security signal. The bridge drove the non-secure bit as 0, secure, for all its traffic, because "the DMA is ours". Any software that could program the DMA controller could then read secure memory. Driving the bit as non-secure, and giving the controller a separate secure channel that only secure software could program, closed the hole.
If software could choose it, non-secure software could simply mark its requests secure.
A defined, conservative value, normally non-secure, so the distinction is never silently upgraded.
Every request must carry who sent it and with what rights: security state, privilege, identity, address space.
Attributes are set by hardware from true state, carried unchanged, and checked at or in front of the target.
Untrusted requesters get their attributes assigned by the fabric; bridges must not drop them.