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.
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)?
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.
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.
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.
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).
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"
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)
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.
Nah, it's not just that, literally all the stuff 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.
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.”
So this was onlz tested on AMD Jaguar CPUs, which are more than 10 years old? It would be good to know how many of the derived attacks can be ported to newer CPUs and whether the controller configuration is now locked down during boot.
Security has advanced a lot in those 10 years, so is it too much to wonder whether this has been quietly addressed already?
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:
- 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
His stuff is something else.
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!
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)?
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.
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.
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.
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.
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).
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?
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"
Could someone ELI5 please? Context, achievement, scope, consequences?
Fascinating. So what is the DCT swizzling functionality designed for in the hardware originally?
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)
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.
[^1]: https://www.youtube.com/watch?v=XH0F9r0siTI
[^2]: https://www.youtube.com/watch?v=jmTwlEh8L7g
He also released another research just a few days ago https://news.ycombinator.com/item?id=49245491
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?!
Seriously. Got tired of reading the same idea over and over reworded endlessly.
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.
Nah, it's not just that, literally all the stuff 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.
Holy crap. This is like a software-reachable version of the dynamic memory aliasing hardware attack demonstrated by https://batteringram.eu/
Opus refuses to discuss this at all. Make of that what you will.
Well, K3 has no problem, Sol is also fine-ish
Is there any word Americans won't use as a verb.
https://en.wikipedia.org/wiki/Spaghettification - "The term was popularized by Stephen Hawking". Hawking was English.
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
nah we'll verb anything
Verbing weirds language.
So this was onlz tested on AMD Jaguar CPUs, which are more than 10 years old? It would be good to know how many of the derived attacks can be ported to newer CPUs and whether the controller configuration is now locked down during boot.
Security has advanced a lot in those 10 years, so is it too much to wonder whether this has been quietly addressed already?