The trick hiding in plain sight: memory addresses aren't as fixed as you think
Every programmer learns early that a variable's memory address is stable — that &x always equals &x, that asking where something lives in memory will give you the same answer twice. This assumption runs so deep it feels like physics. It isn't.
Memory addresses are not fixed by nature. They are fixed by convention, enforced through configuration registers inside the DRAM controller. Change those registers and the entire mapping between physical addresses and actual DRAM cells shifts. What the CPU believed was at address 0x1000 now lands somewhere else entirely. The operating system, the hypervisor, every security boundary built on top of the memory map — all of them move without knowing they moved.
This is exactly what the researcher behind the skitter-creek-bath-salts project demonstrated on AMD Family 16h CPUs. By writing to DRAM controller registers — hardware that sits below the kernel, below System Management Mode, below the Platform Security Processor — the project rewires physical address translation across the entire platform. The memory scrambling this produces doesn't trigger software alarms because no software is watching at that layer. The kernel can't detect the shift. The hypervisor can't detect the shift. The security primitives that protect SMM, PSP firmware, C6 DRAM carveouts, and CPU microcode all assume the memory map underneath them is stable. Once it isn't, those protections dissolve.
AMD Family 16h represents the last CPU generation whose DRAM controller datasheets were publicly documented in enough detail to make this kind of manipulation tractable. That documentation exposed something the security industry had largely ignored: the physical memory subsystem itself is an attack surface, and the access controls guarding the most sensitive regions of DRAM — regions invisible even to the kernel — rest on address translation working exactly as configured at boot.
When address translation becomes attacker-controlled, carve-outs disappear. Regions marked off-limits by hardware become readable and writable. The abstraction that memory-isolation security depends on stops being true, and every lock built on top of that abstraction opens.
What gets exposed: the regions your OS was never supposed to see
Modern x86 platforms quietly partition physical DRAM into regions the operating system cannot see. These carveouts house some of the most sensitive subsystems on the machine: AMD's Platform Security Processor, System Management Mode memory, microcode update staging areas, and the memory regions reserved for C6 power states. Under normal operation, the kernel has no window into any of these spaces. They are physically isolated by design, their addresses mapped out of reach through the DRAM controller's address translation layer.
That isolation is the entire security model. There is no secondary enforcement mechanism underneath it. When DRAM address scrambling corrupts or redirects those translations, the carveouts stop being private. Memory that the kernel could never legally address becomes reachable, because the physical memory protection was never enforced by anything other than mapping integrity.
The consequences are sharpest for SMM and the PSP. System Management Mode operates at a privilege level that sits above Ring 0, above any hypervisor, and outside the visibility of every conventional security tool running on the system. Code executing in SMM is invisible to the OS by definition — the processor suspends normal execution and enters a separate environment with full hardware access. Compromise there means persistent, invisible control over the entire machine.
The PSP operates on a dedicated ARM core embedded in the silicon, running its own firmware before the main CPU boots. It manages cryptographic operations, secure boot attestation, and platform secrets. It is explicitly designed to be unreachable from the host CPU's normal execution environment. Physical memory isolation is what enforces that separation.
When address translation breaks, both environments lose that protection simultaneously. An attacker who can manipulate the DRAM controller's scrambling parameters can redirect reads and writes into regions that firmware and silicon designers treated as permanently off-limits. The memory hierarchy assumed its own integrity. That assumption, it turns out, was never formally guaranteed — and on AMD Family 16h CPUs, where the DRAM controller's internals remain documented, every protected region becomes addressable once the translation layer is undermined.
The missing context most coverage will ignore: this is a class of attack, not a one-off exploit
Most vulnerability disclosures follow a predictable script: a CVE number gets assigned, a patch ships, and the affected software version moves into end-of-life status. The DRAM scrambling attack documented in skitter-creek-bath-salts does not fit that script. There is no CVE to assign here, because the target is not a firmware bug or a misconfigured register. The target is the memory hierarchy itself.
That distinction matters enormously. Security architectures for Trusted Execution Environments, System Management Mode, and CPU-level secure enclaves are all built on one foundational assumption: that physical memory carveouts are inviolable once configured. The Platform Security Processor cannot be read. The microcode patch region cannot be written. The C6 DRAM cannot be touched. These guarantees rest entirely on the premise that a physical address resolves to exactly one location in DRAM, every time, without exception. The research breaks that premise at the controller level, before any protection mechanism gets a chance to enforce anything.
Because the technique operates by manipulating DRAM address translation itself rather than exploiting a flaw in any specific implementation, the conceptual attack surface extends well beyond AMD Family 16h processors. Any platform that uses DRAM carveouts to enforce security isolation, which describes nearly every modern x86 system with firmware-level protections, builds its guarantees on the same architectural assumption being challenged here. Intel TXT, AMD SEV, ARM TrustZone implementations backed by DRAM-resident secure regions — all of them treat the physical memory address as a stable, tamper-resistant boundary.
Patching an architectural assumption is not like patching a buffer overflow. There is no specific line of code to fix. Addressing this class of physical memory isolation bypass requires revisiting how hardware-enforced memory boundaries are specified, how DRAM controllers are documented, and how security models for privileged execution environments are formally verified. The fact that AMD Family 16h was the last processor generation with a publicly documented DRAM controller is itself a data point: opacity became the default, which means similar mechanisms exist in current silicon and the community simply lacks visibility into them.
Why 'just patch it' won't work: the problem with fixing assumptions
The instinct after any hardware disclosure is to ask when the patch drops. With DRAM scrambling attacks, that question has no clean answer.
The DRAM controller registers that skitter-creek-bath-salts manipulates are not bugs hiding in the silicon — they are documented, intentional parts of the hardware interface. Platform management software uses these registers for legitimate memory configuration during boot. Locking them down entirely does not close an attack surface; it dismantles functions the platform depends on. There is no surgical fix available, because the mechanism being abused is also the mechanism the system needs.
AMD's Platform Security Processor was built to enforce a security boundary, but its threat model rested on a foundational assumption: that the physical memory map beneath it was trustworthy and stable. The PSP enforces access controls on carve-outs — protected DRAM regions invisible to the kernel and to normal software. Scramble the address translations at the DRAM controller level, and those carve-outs stop mapping to where the PSP believes they are. The security boundary does not get bypassed; it gets relocated out from under the very subsystem meant to enforce it. Retrofitting memory integrity guarantees at that layer requires architectural changes to how physical address translation and security carve-out enforcement interact — a firmware update cannot reconstruct that foundation.
The microcode problem makes this circularity explicit and uncomfortable. CPU microcode is the primary mechanism AMD and Intel use to deliver patches for processor-level vulnerabilities. It sits in protected DRAM, shielded by exactly the carve-out isolation that physical address scrambling defeats. Skitter-creek-bath-salts lists CPU microcode as one of its direct unlock targets on AMD Family 16h hardware. That means the delivery vehicle for future fixes is itself part of what the attack exposes. A vendor cannot ship a microcode patch to harden the system against an attack that compromises microcode storage without first solving the protection problem the patch was supposed to solve.
Software vulnerabilities have a patch surface: identify the flawed code, replace it, redeploy. Memory subsystem security assumptions baked into silicon across an entire product generation do not have an equivalent corrective path. The attack does not exploit what the hardware does wrong — it exploits what the hardware was always designed to do.
What this means for the security community and everyday users right now
Enterprises and governments running encrypted VM isolation, secure boot chains, or hardware-rooted trust frameworks need to reassess their threat models immediately. The skitter-creek-bath-salts research demonstrates that DRAM carveout isolation — the physical memory segregation that underpins PSP confidentiality, SMM integrity, and microcode protection — can be broken by manipulating the DRAM controller's address translation layer. Any security architecture that treats these carveouts as hard boundaries is built on an assumption that no longer holds.
The attack requires low-level hardware access, which limits immediate risk for most consumers. An attacker cannot exploit this remotely against a standard desktop or laptop without first gaining privileged system access. For ordinary users, the practical danger today is low. What erodes, though, is trust in the marketing language chip vendors have used for years — terms like "hardware-rooted security," "isolated execution environment," and "firmware-level protection" now carry less weight when the physical memory separation beneath them is demonstrably reachable.
For the security research community, the implications extend well beyond AMD Family 16h CPUs, which served as the demonstration platform. The research establishes a new investigative lens: any platform feature protected solely by DRAM region isolation should be treated as a candidate attack surface. Prior assumptions about the confidentiality of Platform Security Processor internals, the inviolability of System Management Mode, and the opacity of CPU microcode need active re-examination across processor families and generations.
Penetration testers assessing data center infrastructure, firmware security auditors reviewing supply chain integrity, and red teams modeling nation-state attack capabilities all have a new class of memory subsystem vulnerabilities to account for. The broader lesson is structural: when security guarantees rest on memory controller behavior that vendors document incompletely or not at all, the absence of a known attack is not proof of safety. The skitter-creek-bath-salts project exposed that gap by working directly from the last AMD generation whose DRAM controller datasheets were fully public — and the technique it revealed has no obvious reason to stop there.
Originally published at Newzlet.
Top comments (0)