Spaghettifying DRAM

MattSteelblade an hour ago | parent | next [-]

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

	▲	Hasz an hour ago \| parent \| next [-]
		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 an hour ago \| parent \| prev [-]
		His stuff is something else.

▲

dzdt an hour ago | parent | prev | next [-]

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 an hour ago \| parent \| next [-]
		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 an hour ago \| parent \| prev [-]
		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.

▲

gmueckl 17 minutes ago | parent | prev | next [-]

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?

	▲	CartwheelLinux 10 minutes ago \| parent [-]
		That information is intentionally left out

▲

dooglius 24 minutes ago | parent | prev | next [-]

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?

	▲	quotemstr 17 minutes ago \| parent [-]
		Even physical DRAM access would be thwarted by transparent mandatory memory encryption, so this hack is still something else.

▲

fulafel an hour ago | parent | prev | next [-]

Fascinating. So what is the DCT swizzling functionality designed for in the hardware originally?

	▲	Retr0id an hour ago \| parent [-]
		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)

▲

devttyeu an hour ago | parent | prev | next [-]

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 17 minutes ago | parent | next [-]

This hack is 99% giving people the control over their own computers they should already have had. Guy is a Robin Hood.

▲

summa_tech an hour ago | parent | prev [-]

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 an hour ago | parent [-]

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 36 minutes ago \| parent [-]
		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"

▲

quotemstr 18 minutes ago | parent | prev | next [-]

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.

▲

aecsocket an hour ago | parent | prev | next [-]

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

	▲	vient an hour ago \| parent [-]
		He also released another research just a few days ago https://news.ycombinator.com/item?id=49245491

▲

ipdashc 43 minutes ago | parent | prev | next [-]

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 22 minutes ago | parent [-]

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 16 minutes ago | parent [-]

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.

▲

boxed 4 minutes ago | parent [-]

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.

	▲	shermantanktop a minute ago \| parent [-]
		[delayed]

▲

Retr0id an hour ago | parent | prev | next [-]

Holy crap. This is like a software-reachable version of the dynamic memory aliasing hardware attack demonstrated by https://batteringram.eu/

▲

UltraSane an hour ago | parent | prev | next [-]

Opus refuses to discuss this at all. Make of that what you will.

▲

devttyeu an hour ago | parent [-]

Well, K3 has no problem, Sol is also fine-ish

	▲	HanClinto 25 minutes ago \| parent [-]
		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. :-/

▲

FabHK 39 minutes ago | parent | prev [-]

Could someone ELI5 please? Context, achievement, scope, consequences?