DMA Security and IOMMU
Overview
DMA engines (Direct Memory Access) are essential for high‑performance SoC operation: they allow peripherals and accelerators to read and write memory without CPU intervention. However, this capability makes them one of the most dangerous attack vectors inside a system.
A compromised or malicious DMA can:
- read sensitive memory regions
- overwrite firmware or secure data
- corrupt cryptographic buffers
- inject forged packets
- bypass software‑based access control
To mitigate these risks, modern SoCs implement a combination of:
- DMA Firewalls
- IOMMU (Input/Output Memory Management Unit)
- Descriptor Validation
- Secure Memory Regions
- Integrity Metadata
- HSM‑controlled access policies
Threat Model
DMA engines operate with high privileges and direct access to memory. If not properly isolated, a DMA can:
- extract cryptographic keys
- tamper with secure boot regions
- corrupt kernel or hypervisor structures
- attack virtual machines
- manipulate network stacks
- bypass CPU privilege checks
In real‑world attacks, DMA has been used to:
- dump firmware
- escalate privileges
- inject malicious packets
- compromise secure enclaves
DMA Firewall Architecture
Each DMA engine must be protected by a dedicated firewall:
The DMA Firewall enforces:
- allowed address ranges
- allowed access types (read/write)
- privilege domain restrictions
- secure vs non‑secure separation
- per‑DMA access policies
- logging and alerting
Example policies:
- DMA0 may access only Ethernet RX/TX buffers
- DMA1 may access only video frame buffers
- Crypto DMA may access only authenticated buffers
- No DMA may access HSM or secure boot regions
IOMMU — Input/Output Memory Management Unit
The IOMMU is the central component for DMA isolation.
Key functions:
- Address Translation Each DMA uses virtual addresses mapped to physical memory through per‑DMA page tables.
- Access Control Each DMA has its own protection domain.
- Isolation Prevents DMA engines from accessing memory belonging to other DMA engines, the CPU, or secure regions.
- Fault Handling Illegal accesses generate faults, interrupts, or security alerts.
IOMMU Pipeline
If translation fails → fault If access is not allowed → deny + alert
Descriptor Validation
Many DMA engines use descriptor rings stored in memory. An attacker could:
- modify descriptors
- redirect DMA to sensitive memory
- change buffer lengths
- alter access flags
Therefore, hardware must validate descriptors:
- address validation
- length checks
- flag verification
- secure region exclusion
- optional integrity metadata
Secure Memory Regions
Memory is divided into regions with different access policies:
| Region | DMA Access | Notes |
|---|---|---|
| Secure Boot | ❌ | Never accessible |
| HSM Memory | ❌ | Never accessible |
| Firmware | ❌ | Secure CPU only |
| Crypto Buffers | ✔️ restricted | Only authorized DMA |
| Data Buffers | ✔️ | Controlled access |
| Shared Memory | ✔️ | With IOMMU protection |
DMA Integrity Metadata
To prevent spoofing and replay, some SoCs attach metadata to DMA transactions:
- transaction ID
- domain ID
- integrity tag
- freshness counter
- privilege level
This prevents:
- DMA ID spoofing
- replay of old transactions
- privilege escalation
HSM Integration
The HSM may control:
- DMA access policies
- keys for descriptor authentication
- secure memory region definitions
- logging of DMA violations
- lifecycle‑based restrictions
Example flow:
In production lifecycle states, certain DMA capabilities may be disabled entirely.
DMA Attack Examples and Mitigations
| Attack | Description | Mitigation |
|---|---|---|
| DMA reads secure memory | Peripheral extracts keys | IOMMU + firewall |
| DMA overwrites firmware | Bootloader corruption | Secure regions + deny |
| DMA injects packets | Network stack attack | Descriptor validation |
| DMA corrupts crypto buffers | Protocol compromise | Integrity metadata |
| DMA bypasses CPU checks | Direct RAM access | Per‑DMA page tables |
