Bus Firewalls and Memory Isolation
Overview
Modern SoCs contain multiple bus masters:
- CPU cores
- DMA engines
- accelerators
- peripheral controllers
- debug interfaces
- network engines
Any of these masters can potentially access memory or registers they should not. Bus firewalls and memory isolation enforce strict boundaries inside the SoC, preventing:
- unauthorized memory access
- privilege escalation
- data corruption
- key extraction
- bypass of security features
These mechanisms are essential for a secure architecture, especially when combined with:
- HSM
- secure boot
- PUF‑derived keys
- MACsec/IPsec engines
- DMA security
- secure debug
Threat Model
Without bus firewalls, a malicious or compromised master can:
- read secret keys from memory
- overwrite firmware
- corrupt buffers
- inject packets
- disable security registers
- access HSM interfaces
- bypass isolation between CPU cores
- attack secure boot regions
This is why internal buses must be treated as untrusted, even inside the chip.
Bus Firewall Architecture
A bus firewall is a hardware block placed between a master and the interconnect:
Firewall responsibilities:
- address range enforcement
- privilege level enforcement
- domain isolation
- read/write filtering
- transaction tagging
- policy enforcement
- logging and alerting
Typical firewall checks:
- Is this master allowed to access this address?
- Is the access type allowed (read/write/execute)?
- Is the master in the correct privilege domain?
- Is the transaction tagged correctly?
- Is the access aligned with lifecycle state?
If any check fails → drop + alert.
Transaction Tagging and Domains
Modern interconnects (AXI, CHI, TileLink) support transaction metadata:
- master ID
- security domain
- privilege level
- virtual machine ID
- process ID
- secure/non‑secure bit (TrustZone‑style)
Bus firewalls use these tags to enforce:
- isolation between CPU cores
- isolation between secure and non‑secure worlds
- isolation between DMA engines
- isolation between virtual machines
- isolation between firmware and accelerators
Memory Isolation
Memory isolation ensures that different regions of memory are accessible only to authorized masters.
Memory isolation mechanisms:
- MPU (Memory Protection Unit)
- MMU (Memory Management Unit)
- IOMMU (for DMA)
- Secure/Non‑Secure partitions
- HSM‑protected memory regions
- Execute‑Never (XN) regions
- Read‑Only regions
- Key vaults inside accelerators
Example: Secure Boot Region
Only the secure CPU can read the boot ROM.
End‑to‑End Integrity and Isolation
Bus firewalls are often combined with integrity metadata:
- per‑transaction MAC
- replay counters
- freshness tags
- domain identifiers
This ensures that even if a master tries to spoof its identity, the firewall detects it.
Firewall Placement in the SoC
Typical placement:
Strict firewalls
Protect HSM, secure boot, key vaults.
Moderate firewalls
Protect memory, DMA, accelerators.
Firewall Policy Engine
Firewall policies are configured by:
- secure boot ROM
- lifecycle fuses
- HSM
- secure firmware
Policies include:
- allowed address ranges
- allowed masters
- allowed access types
- allowed privilege levels
- debug restrictions
- DMA restrictions
Policies must be immutable after boot (or controlled by HSM).
Memory Isolation for DMA
DMA engines are the most dangerous masters because they bypass the CPU.
Memory isolation for DMA is implemented via:
- IOMMU
- per‑DMA firewalls
- descriptor validation
- integrity metadata
- secure memory regions
This prevents:
- DMA‑based key extraction
- DMA‑based firmware overwrite
- DMA‑based buffer corruption
Firewall Violation Handling
When a firewall detects a violation:
- the transaction is dropped
- an alert is sent to the security monitor
- optional interrupt to CPU
- optional escalation to HSM
- optional lockdown of the offending master
In high‑security SoCs, repeated violations trigger:
- master quarantine
- bus isolation
- key zeroization
- system reset
Threats and Mitigations
| Threat | Mitigation |
|---|---|
| Malicious DMA | IOMMU + DMA firewalls |
| CPU compromise | HSM‑controlled policies |
| Bus spoofing | Transaction tagging + integrity |
| Memory corruption | Read/write filtering |
| Key extraction | HSM isolation + secure memory |
| Debug bypass | Debug firewall + lifecycle gating |
| Replay attacks | Freshness counters |
