Unlocking _everything_ on the CPU with DRAM scrambling
40 points by radex
40 points by radex
I'm sure there's an interesting thing in here but I really can't read the "sensationalist" slop writing style :(
Agreed, I am sick of it, as well. As soon as one smells the clanker's oil on a piece of text, one knows the social contract of someone having had to spend more time writing it than you need to read it was broken.
The style of writing in the README was the most interesting thing you took away from this project? Really?
I wanted to find this interesting, but I found the slop so fatiguing it turned me off entirely.
It's fishing for detail in a sea of words that look enough like detail to keep you fishing, but aren't.
A short description if you can’t stand the slop-readme: https://chaos.social/@gsuberland/117089697867842435
The details of this are way over my head, but the thing that surprises me most is that the bits that tell the DRAM chips what scrambling to apply are not only available from the CPU, they're, apparently, mapped to an accessible virtual address (in kernelspace). The author says that they picked this particular processor family (which is from 2013) because its data sheet was just a little too transparent, which is fair game, but could it be that the specialness of this processor family is not the openness of the datasheet, but the fact that these control bits are accessible in the first place?
Surely there are people in the hardware design space -- at AMD or Intel, say -- who know how this stuff works and who understand that being able to modify the (physical address) <-> (DIMM channel/rank/bank address) mapping while a system is running may well undermine security components working in physical address space? Would those people not ensure that those physical addresses are not accessible by CPU cores whatsoever?
In fact my surprise starts even earlier: sure, DRAM chips exposing configuration knobs users aren't meant to touch is not so strange, but why expose those knobs as memory with a physical address? Does the protocol over the DRAM connector not allow anything else than a memory access at a well-defined physical address?
There's so much wat here.
In fact my surprise starts even earlier: sure, DRAM chips exposing configuration knobs users aren't meant to touch is not so strange, but why expose those knobs as memory with a physical address? Does the protocol over the DRAM connector not allow anything else than a memory access at a well-defined physical address?
I assume that this is not something being done by the RAM chip – my reading of the article is that it's an MMIO register exposed by the memory controller block on the CPU.
could it be that the specialness of this processor family is not the openness of the datasheet, but the fact that these control bits are accessible in the first place?
It's probably not unusual for these bits to be exposed - they have to exposed at some point for the firmware to be able to tweak them at all - but usually for security-sensitive (SMM-bypassing) registers there's a "lock" function that the firmware would use to prevent the register being manipulated after control has been handed to the OS. Such a lock seems to be missing in this case.
DRAM chips exposing configuration knobs users aren't meant to touch is not so strange, but why expose those knobs as memory with a physical address?
It's not the DRAM chips exposing these knobs. They're in the memory controller, which in modern CPUs is integrated on the processor die.
They're exposed as physical addresses because there needs to be some way for firmware which runs on the processor to twiddle them. There are other ways to expose them but they wouldn't be solving the problem - the firmware needs to set up whatever scheme best matches the hardware outside the processor, so they must be exposed in a way that software running on the processor can touch, and MMIO (i.e. physical addresses) is the simplest. Other ways are available but would probably require more logic on the processor die and wouldn't make the problem any better anyway.
Thank you! This makes things much clearer and more concrete. The fact that there's a lock missing on the address simultaneously explains why this may accidentally happen on a particular microarchitecture and why this is probably not a thing on others, where that mistake wasn't made. It also puts the real-world impact of the effect into a more realistic footing.
And thanks re MMIO stuff, I knew nothing about this but now I know nonzero, which is great. :)
Assuming this is fixed or will be universally fixed next generation.
Some dishonest vendors love flash chips which have multiple «allegedly physical» addresses correspond to the same real physcial address. A bit of a chore to text quickly what is the true capacity of a chip.
Is there somewhere a DRAM module that secretly does the same? Once it is known that there is, no more use of physical DRAM encryption (presumably, position-dependent in an annoying way) as a distinguishing feature for most expensive server CPUs!
Some dishonest vendors love flash chips which have multiple «allegedly physical» addresses correspond to the same real physcial address. A bit of a chore to text quickly what is the true capacity of a chip.
This is pretty much all of them, since the standard interface for flash chips have distinct address lines. If an address line isn't connected, the flash won't see it, and thus it loops from the perspective of whoever is accessing it.
The question is whether this happens (way) below the reported capacity!
I've yet to see an actual chip do it (you would essentially need to deliberately fabricate ones that does so, which ends up more expensive than just reselling working ones) so it tends to be done on the integrator side (USB sticks, etc)
Does the protocol over the DRAM connector not allow anything else than a memory access at a well-defined physical address?
The protocol over the DRAM connector (i.e. DIMM) operates in terms of bits, rows and columns, not physical addresses. Byte addresses, be it physical or otherwise, only come into existence at the CPU end of the memory controller (whose behavior is what's being manipulated here).
Ah! Thanks. I tried to read that big snake diagram but apparently I failed to pick up this part.