When I started with computers, DRAM was understandable by a teenager: RAS, CAS, read, done.
Ok, the necessary refresh was always a little pain, but still something manageable.
Nowadays, I feel you need three PhD's to even bring up a micro with DRAM and don't get me started on the proprietary binary blobs necessary just for DRAM access. No wonder PSRAM is a thing.
The corollary is that it shouldn't be too surprising that this gigantic attack surface provides many opportunities. (Of course that doesn't mean it is easy to find them
MattSteelblade 2 hours ago [-]
I cannot wait for the accompanying Black Hat talk. Christopher Domas is one of my absolute favorite all-time hackers. He does such a fantastic job of explaining his work. Some of my favorite talks of his:
If this is the same dude I am thinking of, his wife is also the CISO of Mozilla and do security research together, afair they have a whole book on x86 reverse engineering.
Very cool!
jambalaya8 2 hours ago [-]
His stuff is something else.
ecshafer 2 minutes ago [-]
This is so cool. Outside of a cool demo, and maybe some black hat type stuff, this is surely dangerous, a bad idea, and shouldn't be done in prod. But pure hacker ethos at its heart.
WhiteDawn 43 minutes ago [-]
This is all great to get full unfettered access to your own system, as life should be.
I’m sure Xbox and PlayStation security groups are a little nervous right now though. Getting ring-0 on those machines is near impossible, but once you do then everything else becomes wide open
ransom_rs 26 minutes ago [-]
Seems like this should get us a newer PS4 jailbreak?
gmueckl 1 hours ago [-]
OK, so this works on AMD Jaguar according to the README. That's a architecture from 2013. There's notes about Zen 3 having a different base address for the memory controller registers, but that's it. What newer CPUs does attack actually work on?
devttyeu 54 minutes ago [-]
Zen has completely different memory controller IP (UMC), that's configured at boot by AGESA/PSP. I doubt this exploit applies to modern Zen CPUs, however AMD are the only ones who could really confirm this.
CartwheelLinux 1 hours ago [-]
That information is intentionally left out
gmueckl 53 minutes ago [-]
Then publishing it in this incomplete state is just pointless fearmongering and will just make others fill in this information within the next couple of days. And the good guys likely won't be the first ones to do that.
dzdt 2 hours ago [-]
So on an affected system, ring 0 root has access to pretty much everything that was hidden in negative ring territory. The page is pretty quiet about what other processor families might be similar beyond this specific AMD16h (an older AMD low-power family)?
m1el 2 hours ago [-]
from the GH page:
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.
embedding-shape 2 hours ago [-]
As long as you know the controller's translation registers, it's applicable? Not tested on later one's merely because the information wasn't readily available it seems.
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.
zahlman 26 minutes ago [-]
This is only applicable if you already have root (in order to get beyond that), right? It doesn't expose new risk of local privilege escalation?
odo1242 21 minutes ago [-]
Yep, I believe so
Permik 18 minutes ago [-]
Skitter creek bath salts... Or SCBS
Guess there'll be a talk called Secure Computing BullShit in the next Blackhat conf! I'll be eagerly waiting for it! :)
dooglius 1 hours ago [-]
I don't understand the threat model being attacked here. If you had physical DRAM access you could do all of this anyway right? And I would assume that an unprivileged user would not have write access to the DRAM controller registers?
fulafel 54 minutes ago [-]
This doesn't require physical DRAM access, it's all software.
With ring-0 access, this lets you poke "even things walled off and invisible to ring-0 or the CPU itself" including things that the security processor tries hard to wall off.
VorpalWay 34 minutes ago [-]
Which arguably is a good thing. As a owner of the system I really should have complete control over it. But currently there is software I have no control over running at even higher privilege levels.
The only modern silicon that gives me full control over what code is running is some (or most?) microcontrollers.
And this isn't just a question of FOSS principle. Especially SMM is problematic by unpredictably taking CPU cycles away from your workload. This can mess up hard realtime workloads, such as found in CNC controllers. If you are running something like LinuxCNC this something you need to measure to figure out if a given computer is suitable for that job.
quotemstr 1 hours ago [-]
Even physical DRAM access would be thwarted by transparent total memory encryption, so this hack is still something else.
devttyeu 2 hours ago [-]
The big question is whether this can break out of KVM and whether it can be microrode patched / patched in any other way.
And whether it's really real in the first place.
quotemstr 1 hours ago [-]
This hack is 99% giving people the control over their own computers they should already have had. Guy is a Robin Hood.
MSFT_Edging 12 minutes ago [-]
When Chris Domas left Battelle for Intel years back, shortly after hardware-fuzzing a bank of thin-clients to discover undocumented x86 instructions, I was convinced Intel was basically keeping him on the payroll to shut him up.
summa_tech 2 hours ago [-]
One hopes that a hypervisor would not expose hardware control registers directly in the first place, except ones deliberately designed for virtualization support.
Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).
devttyeu 2 hours ago [-]
Yeah, just started looking at this with my team (we run a cloud with VM instance offering on AMD so this very much caught our eye)
So far seems this is about right:
1. You need platform register access, so seems can't KVM-escape with just this
2. Big question is what about breaking Confidential SEV-SNP guests from the host?
devttyeu 2 hours ago [-]
Ok, on 2. and in general this exploit only works on pre-Zen AMD platforms as the repo states in not-so-clear terms.
Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
pocksuppet 7 minutes ago [-]
This is probably very interesting, but does it really have to be explained with a solid wall of AI slop writing?
fulafel 2 hours ago [-]
Fascinating. So what is the DCT swizzling functionality designed for in the hardware originally?
Retr0id 2 hours ago [-]
Without any swizzling, certain common access patterns can end up with subpar performance, for example walking the columns of a 2d array with a certain stride - if it ends up directing every access to the same bank on the same channel, the throughput is much lower than if the load was evenly distributed across multiple banks/channels.
Swizzling "randomizes" bank/rank/channel distribution, which makes unlucky access patterns less likely. (Something I'd like to research is microbenchmarking different access patterns to infer the swizzle pattern and defeat physical ASLR)
ipdashc 2 hours ago [-]
I really hate to be that guy, but man, as someone who was and is a big Christopher Domas fan (and is way dumber than him, I mean, this stuff is seriously over my head)... it's been really disappointing to see him LLM'ing all the READMEs recently. They used to be a joy to read through, but now the Claudeisms made it such a slog I could barely get through a few paragraphs. I'm glad he's using the new tools to get even more cool stuff done, but I wish he'd have gone for a human writeup at the end.
BugsJustFindMe 1 hours ago [-]
I find vague gestures like this almost more annoying than the idea of someone using AI to write.
> the Claudeisms
This is hand-waving. Please be more specific.
> made it such a slog
On the flip-side, I didn't find it a slog at all. What if you're wrong?
austinthetaco 1 hours ago [-]
I'm not the person you are replying to, but the readme is very clearly written by an AI, and it sounds nothing like his older work. Sometimes it's just super clear to people something is written with AI without you getting some sort of singular "gotcha" word or indicator. It's just writing patterns that would be hard to clearly establish rules for here in an HN comment, but it's incredibly obvious when you learn to spot it.
gnyman 51 minutes ago [-]
I recently vibed a little linked-in AI detector which looks for AI things like rule of three and scores it. It scored it 97% AI polished.
My gut feeling agrees. The rule of three is one of the stronger signals, can't stamp that out of the AI even if you wanted :-)
I'll push it to GH later, it's nothing fancy but it has been quite good in my experience. Here is highlights which it used
```
tricolon coordinated VERB run: “…break / on them collapse / unlock everything .” (3 members)
tricolon coordinated VERB run: “…guard physical addresses / not DRAM coordinates / you rearrange the” (3 members)
tricolon coordinated NOUN run: “…handful of data / it to z3 / the translation matrix” (3 members)
tricolon coordinated NOUN run: “…view / the elaborate fences / locks / security checks the” (4 members)
tricolon coordinated VERB run: “…Read it / the alias map / pipe” (3 members)
```
boxed 1 hours ago [-]
I mean, it's super clear to a lot of people that it's written by LLMs EVEN WHEN IT'S NOT. You can't vibe that shit too.
rustyminnow 49 minutes ago [-]
How do you know when it's not written by LLM except to take someone's word? If I got caught slopping I'd be too embarassed to admit it. "I wrote it all myself! I actually majored in slick writing and minored in tenuous metaphor."
shermantanktop 57 minutes ago [-]
I just told my boss to remove a line in a doc because it sounded too AI-y. He then said that he had written it himself.
jchw 49 minutes ago [-]
"What if you're wrong?"
I'd just like to address this real quick because some people seem to think this is just a "hunch" that has some probability of being false; there is absolutely nothing more certain on planet Earth than the LLM involvement in this writing. It is difficult to come up with things that are certain enough to compare this to to convey the lack of doubt that exists.
I am not going to make fun of you for not being able to tell, although I do find it surprising that people seem to struggle in both directions with telling AI and human writing apart (are our brains really that different?) - I just want it to be clear that some of us can pick up Claudisms within just a couple of sentences with no effort. A Claude-generated sentence, in isolation, may not ring any alarm bells. A few of them in a row, however, that's a load-bearing smoking gun right there.
We can certainly argue to what extent undisclosed LLM involvement is an issue or not, though frankly I don't like reading LLM writeups so I would greatly prefer if people would stop using LLMs for public facing documents. But, it is at least worth making this much clear: we can tell.
jonathrg 43 minutes ago [-]
The only other reasonable explanation would be that he has consumed so much LLM content that the machine has erased his voice and replaced it with its own.
ipdashc 55 minutes ago [-]
> Please be more specific.
The em dashes are the most obvious stereotypical tell, but that doesn't really matter that much (I actually like them and occasionally used them pre-AI). It's hard to put a finger on, but the most annoying LLMism to me is the overdramatic, staccato, almost "epic" way they talk. It feels like a 2009 lens flare effect over everything, it sounds like a stereotypical hacker in a CSI show.
> the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked
> When your code dereferences *p, it appears to access the DRAM at p. It does not — p is a virtual address
> Physical addresses are really more of a suggestion.
> That's the exploit. All of it.
The worst part is that this stuff is genuinely cool and deserves to be dramatic. And I like stereotypical, campy hacker speak! But LLMs are, IDK... bad at it? Or maybe it just becomes a bore to read the same. Exact. Dramatic. Voice. From literally everyone. After you've heard it enough times.
None of this is against Mr. Domas. He seems like a cool person, with a cool voice, and I want to read his voice, not Claude's.
> What if you're wrong?
I definitely could be! Apologies if I am. But with all the em dashes and such, and having read his previous work, I felt confident enough to mention it. And as the sibling comment says, it really is something you just learn to spot over time.
cgyvbunji 46 minutes ago [-]
It's the ASCII diagrams for me. Although I hesitate to point it out because they are usually helpful unlike the em dashes. Before LLMs, ASCII diagrams in readmes were a half baked mess, if one were present at all. Now every project has at least one perfectly made ASCII diagram - instant LLM tell.
ipdashc 39 minutes ago [-]
> Although I hesitate to point it out because they are usually helpful unlike the em dashes.
Likewise, I don't mind the diagrams. Though they do often have the same flaw as other text, being that the LLM throws in EVERYTHING, vs. a handmade one that'd generally have more taste and discretion to it. That can kind of work in its favor here, since the point is just to show the complexity of the stack, but on the other hand the reader lacks confidence that every item in there is "really" a part of the stack (which I would be fully confident in for this author, had he written it by hand) and not just some process related to memory/DRAM that the LLM decided to toss in.
pwf 52 minutes ago [-]
[dead]
1 hours ago [-]
aecsocket 2 hours ago [-]
Holy shit, Christopher Domas is back. I remember watching his Defcon talks on x86 shenanigans[^1][^2] and being amazed at what he's been able to discover. Then he got whisked away by Intel and now drops this. I'm excited.
The researcher behind this is obviously highly knowledgeable in reverse engineering CPUs to the tune it reminds me of the dwarves digging in Moria...
But why on earth do they have to use AI to write their writeups?!
russdill 2 hours ago [-]
Seriously. Got tired of reading the same idea over and over reworded endlessly.
dcrazy 2 hours ago [-]
I got suspicious but decided it wasn’t AI. The “Foo is the bar.” sentence construct is coherent with the overall “through the looking glass” tenor.
jchw 1 hours ago [-]
Nah, it's not just that, literally all the stuff they've posted this year is obvious LLM writing, none of the stuff from previous years is. To get this close to LLM writing style without actually using an LLM, you would pretty much have to be purposefully trying.
But I have a new favorite way of demonstrating this:
Like, who cares? In today's present, I wouldn't bother writing the article myself neither besides giving the instructions and auditing the output. Substance is what matters
pocksuppet 5 minutes ago [-]
Did you test the substance? Did it work? AI can hallucinate substance.
quotemstr 1 hours ago [-]
This is the level of access the rightful owner of a computer should have to his own system.
He should also be able to fuse away this access forever, to be fair. But out of the box, when I get a new laptop, I should be able to read and write every byte of DRAM.
Retr0id 2 hours ago [-]
Holy crap. This is like a software-reachable version of the dynamic memory aliasing hardware attack demonstrated by https://batteringram.eu/
pocksuppet 3 minutes ago [-]
Oh that's a clever attack. The RAM bus was often thought of as off-limits because of the speed and signal integrity requirements. They bypassed those.
UltraSane 2 hours ago [-]
Opus refuses to discuss this at all. Make of that what you will.
rustcleaner 18 minutes ago [-]
Guardrails are a product-quality smell. Boycott guardrailed models. Punish guardrailed model providers with reduced revenue and bankruptcy. "I'm sorry Dave" must become a subscription-cancelling response or the nannying will never stop!
devttyeu 2 hours ago [-]
Well, K3 has no problem, Sol is also fine-ish
HanClinto 1 hours ago [-]
Likewise -- also had zero issues going over this with Sol. Seemed to give solid advice for how to test it -- use an expendable bare-metal AMD family 16h test system w/ usual standard checks that apply.
> Run `platform_check` first and do not use `SKITTER_FORCE=1` casually. Start with the read-only `dram_state` and `dram_carveouts`, then `dram_dump --dry-run`. Avoid `dram_poke` until maps have been freshly collected and calibrated. Do not bypass fingerprint checks, calibration, fencing, or verification.
Claude's (apparently externally-mandated?) lobotomization continues to be concerning. :-/
Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that's all.”
-- Alice in Wonderland
ImJasonH 2 hours ago [-]
nah we'll verb anything
fred256 2 hours ago [-]
Verbing weirds language.
FabHK 2 hours ago [-]
Could someone ELI5 please? Context, achievement, scope, consequences?
self_awareness 34 minutes ago [-]
[flagged]
2 hours ago [-]
Rendered at 17:10:49 GMT+0000 (Coordinated Universal Time) with Vercel.
Ok, the necessary refresh was always a little pain, but still something manageable.
Nowadays, I feel you need three PhD's to even bring up a micro with DRAM and don't get me started on the proprietary binary blobs necessary just for DRAM access. No wonder PSRAM is a thing.
The corollary is that it shouldn't be too surprising that this gigantic attack surface provides many opportunities. (Of course that doesn't mean it is easy to find them
- Psychological Warfare in Reverse Engineering https://www.youtube.com/watch?v=HlUe0TUHOIc
- The MoVfuscator https://www.youtube.com/watch?v=R7EEoWg6Ekk
- Hardware Backdoors in redacted x86 https://www.youtube.com/watch?v=jmTwlEh8L7g
Very cool!
I’m sure Xbox and PlayStation security groups are a little nervous right now though. Getting ring-0 on those machines is near impossible, but once you do then everything else becomes wide open
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.
With ring-0 access, this lets you poke "even things walled off and invisible to ring-0 or the CPU itself" including things that the security processor tries hard to wall off.
The only modern silicon that gives me full control over what code is running is some (or most?) microcontrollers.
And this isn't just a question of FOSS principle. Especially SMM is problematic by unpredictably taking CPU cycles away from your workload. This can mess up hard realtime workloads, such as found in CNC controllers. If you are running something like LinuxCNC this something you need to measure to figure out if a given computer is suitable for that job.
And whether it's really real in the first place.
Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).
So far seems this is about right:
1. You need platform register access, so seems can't KVM-escape with just this
2. Big question is what about breaking Confidential SEV-SNP guests from the host?
Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
Swizzling "randomizes" bank/rank/channel distribution, which makes unlucky access patterns less likely. (Something I'd like to research is microbenchmarking different access patterns to infer the swizzle pattern and defeat physical ASLR)
> the Claudeisms
This is hand-waving. Please be more specific.
> made it such a slog
On the flip-side, I didn't find it a slog at all. What if you're wrong?
My gut feeling agrees. The rule of three is one of the stronger signals, can't stamp that out of the AI even if you wanted :-)
I'll push it to GH later, it's nothing fancy but it has been quite good in my experience. Here is highlights which it used
``` tricolon coordinated VERB run: “…break / on them collapse / unlock everything .” (3 members) tricolon coordinated VERB run: “…guard physical addresses / not DRAM coordinates / you rearrange the” (3 members) tricolon coordinated NOUN run: “…handful of data / it to z3 / the translation matrix” (3 members) tricolon coordinated NOUN run: “…view / the elaborate fences / locks / security checks the” (4 members) tricolon coordinated VERB run: “…Read it / the alias map / pipe” (3 members) ```
I'd just like to address this real quick because some people seem to think this is just a "hunch" that has some probability of being false; there is absolutely nothing more certain on planet Earth than the LLM involvement in this writing. It is difficult to come up with things that are certain enough to compare this to to convey the lack of doubt that exists.
I am not going to make fun of you for not being able to tell, although I do find it surprising that people seem to struggle in both directions with telling AI and human writing apart (are our brains really that different?) - I just want it to be clear that some of us can pick up Claudisms within just a couple of sentences with no effort. A Claude-generated sentence, in isolation, may not ring any alarm bells. A few of them in a row, however, that's a load-bearing smoking gun right there.
We can certainly argue to what extent undisclosed LLM involvement is an issue or not, though frankly I don't like reading LLM writeups so I would greatly prefer if people would stop using LLMs for public facing documents. But, it is at least worth making this much clear: we can tell.
The em dashes are the most obvious stereotypical tell, but that doesn't really matter that much (I actually like them and occasionally used them pre-AI). It's hard to put a finger on, but the most annoying LLMism to me is the overdramatic, staccato, almost "epic" way they talk. It feels like a 2009 lens flare effect over everything, it sounds like a stereotypical hacker in a CSI show.
> the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked
> When your code dereferences *p, it appears to access the DRAM at p. It does not — p is a virtual address
> Physical addresses are really more of a suggestion.
> That's the exploit. All of it.
The worst part is that this stuff is genuinely cool and deserves to be dramatic. And I like stereotypical, campy hacker speak! But LLMs are, IDK... bad at it? Or maybe it just becomes a bore to read the same. Exact. Dramatic. Voice. From literally everyone. After you've heard it enough times.
None of this is against Mr. Domas. He seems like a cool person, with a cool voice, and I want to read his voice, not Claude's.
> What if you're wrong?
I definitely could be! Apologies if I am. But with all the em dashes and such, and having read his previous work, I felt confident enough to mention it. And as the sibling comment says, it really is something you just learn to spot over time.
Likewise, I don't mind the diagrams. Though they do often have the same flaw as other text, being that the LLM throws in EVERYTHING, vs. a handmade one that'd generally have more taste and discretion to it. That can kind of work in its favor here, since the point is just to show the complexity of the stack, but on the other hand the reader lacks confidence that every item in there is "really" a part of the stack (which I would be fully confident in for this author, had he written it by hand) and not just some process related to memory/DRAM that the LLM decided to toss in.
[^1]: https://www.youtube.com/watch?v=XH0F9r0siTI
[^2]: https://www.youtube.com/watch?v=jmTwlEh8L7g
But why on earth do they have to use AI to write their writeups?!
But I have a new favorite way of demonstrating this:
https://github.com/search?q=owner%3Axoreaxeaxeax+load-bearin...
Guess how many of these are from before 2025.
He should also be able to fuse away this access forever, to be fair. But out of the box, when I get a new laptop, I should be able to read and write every byte of DRAM.
> Run `platform_check` first and do not use `SKITTER_FORCE=1` casually. Start with the read-only `dram_state` and `dram_carveouts`, then `dram_dump --dry-run`. Avoid `dram_poke` until maps have been freshly collected and calibrated. Do not bypass fingerprint checks, calibration, fencing, or verification.
Claude's (apparently externally-mandated?) lobotomization continues to be concerning. :-/
Odd, he had an American accent.
-- Alice in Wonderland