BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News DRAM Controller Register Manipulation Breaks CPU Memory Isolation

DRAM Controller Register Manipulation Breaks CPU Memory Isolation

Listen to this article -  0:00

Security researcher Christopher Domas has unveiled skitter-creek-bath-salts, an open-source hardware security project that dismantles traditional CPU privilege boundaries by targeting the lowest layer of the physical memory hierarchy. By manipulating memory controller translation registers, the tool dynamically alters physical-to-DRAM address mappings at the hardware logic level. This enables unprivileged software to access isolated platform memory regions without triggering upstream architectural memory fences or fault exceptions.

Modern processor security architectures assume that physical addresses map deterministically to specific silicon storage locations. Standard security boundaries—including hypervisor Extended Page Tables, System Management Mode TSEG range limits, and Platform Security Processor (PSP) private carveouts—operate at the core and system fabric interconnect layer, before memory traffic reaches the controller. Domas discovered that memory controller translation registers sit beneath these access-control fences. Manipulating configuration bits, such as BankSwizzleMode, fundamentally changes how the controller calculates DRAM bank, row, and column coordinates. Because upstream security filters only validate the untranslated physical address, these bit-flips allow standard memory accesses to land silently inside protected hardware enclaves.

To extract data from scrambled memory without destabilizing the host OS, the exploit utilizes a multi-stage software pipeline. A custom Linux kernel module offlines non-boot CPU cores, flushes system caches, pre-warms translation lookaside buffers, and disables interrupts to ensure memory stability during rewiring. Automated probing scripts then use a coupon-collector heuristic, combined with targeted userspace reads, to catalogue address bit collisions. The accompanying toolchain models the physical address permutation using Galois Field arithmetic and employs an SMT solver to derive the exact bitwise mapping. Once the map is resolved, the exploit executes targeted read/write bursts against previously impenetrable enclaves, including System Management Mode (SMM) RAM, PSP firmware tables, CC6 processor sleep save areas, and microcode patch buffers.

These findings expose a critical architectural blind spot: upstream security checks cannot guarantee integrity if downstream memory controller logic permits dynamic address swizzling, posing risks to bare-metal cloud and confidential computing. This vulnerability highlights the vital distinction between CPU and platform privilege. While AMD Family 14h, 15h, and 16h processors allow Ring 0 software to manipulate these configurations, this access level is fundamentally insufficient, as it treats the kernel as inherently trusted. To secure future systems, hardware teams must ensure memory controller translation registers are strictly locked during boot, as the reality of adversarial kernels demands that security-critical platform configuration be managed by boundaries elevated above CPU-level privilege.

Hardware security and reverse-engineering communities on Reddit (e.g., r/asm and r/blueteamsec) and podcasts like SANS ISC Stormcast have responded to the project with significant interest. Discussions have centered on the architectural implications of the discovery, noting that because platform security fences exist above the memory controller, they remain oblivious to the scrambling of raw physical coordinates. Experts also emphasize the practical limitations of the exploit, which requires Ring 0 privileges and targets registers primarily accessible on older AMD Family 15h and 16h processors.

About the Author

Rate this Article

Adoption
Style

BT