row hammer...

[Jasen Betts]

On 2020-09-04, Tom Del Rosso <fizzbintuesday@that-google-mail-domain.com> wrote:

Don Y wrote:
On 9/3/2020 8:56 PM, Tom Del Rosso wrote:
Lasse Langwadt Christensen wrote:

afaiu it is not an x86 problem it is a RAM problem and has been
demonstrated on ARM devices too

Assuming the exploit would need to hammer more than one consecutive
row, could the board maker do something by swapping some of the
address bits?

You repeatedly access the (physically!) adjacent row. Or, the rows on
either side of the row being attacked.

But there\'s no reason the physical and logical order of rows has to
match.



With different bits swapped in each board model, the exploit would
have a tough job.

You\'d likely also have to tweek the memory controller\'s
initialization of the devices.

I know you can\'t swap just any address lines because that would
defeat several kinds of fast addressing modes, but maybe there are
some possibilities.

Easier to link the modules in different orders so stuff ends up in
different places. Of course, that assumes there is no way that this
information leaks in other ways!

Note that you can notice who (task ID) is \"current\" when the *likely*
ECC action takes place. If you\'re always encountering EDAC problems
while \"foo()\" is executing, then perhaps foo() needs to be 86-ed!

A few minutes after posting I realized that the RAM makers could do it
more effectively than the board makers, by mixing up the order of rows.
If every model of chip did that differently the exploit would never
work. There is no way to tell what RAM chips are in the system is there?
The type of RAM can be seen but not the brand.

You can get all that using \"dmidecode\":

Memory Device
Array Handle: 0x0038
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: ChannelA-DIMM1
Bank Locator: BANK 0
Type: DDR4
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 2666 MT/s
Manufacturer: A-DATA
Serial Number: 745C0300
Asset Tag: 9876543210
Part Number:
Rank: 1
Configured Memory Speed: 2666 MT/s
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: 1.2 V

On Linux you need to be root to run dmidecode, so it would still be
hard for an attacker to get that information.

--
Jasen.

 

[Don Y]

On 9/5/2020 5:34 AM, Jasen Betts wrote:

A few minutes after posting I realized that the RAM makers could do it
more effectively than the board makers, by mixing up the order of rows.
If every model of chip did that differently the exploit would never
work. There is no way to tell what RAM chips are in the system is there?
The type of RAM can be seen but not the brand.

You can get all that using \"dmidecode\":

Memory Device
Array Handle: 0x0038
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: ChannelA-DIMM1
Bank Locator: BANK 0
Type: DDR4
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 2666 MT/s
Manufacturer: A-DATA
Serial Number: 745C0300
Asset Tag: 9876543210
Part Number:
Rank: 1
Configured Memory Speed: 2666 MT/s
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: 1.2 V

On Linux you need to be root to run dmidecode, so it would still be
hard for an attacker to get that information.

This information is derived from the SPD component(s) on the DIMM, not
from the memory components themselves. (you don\'t need a DIMM form
factor to use SDRAM!)

E.g., a system with \"soldered down\" SDRAM *chips* is under no obligation
to support such an interface. The mode registers in the SDRAM chips
are essentially write-only; they rely on the host CPU knowing what
information should be crammed into them -- much like the early IDE
drives required the BIOS to *tell* them what their drive geometries
were.

While SOME of this information will be available \"in the code\" (used
to initialize the memory and memory controller), it will likely NOT be
in some \"universally\" structured form. And, some of it will likely
not be present at all. E.g., my code doesn\'t need to know that the
memory devices that require these particular timing values are
manufactured by Micron vs. People\'s Memory Manufacturer #24. So,
an exploit that targets a PMM device may not be effective if this
board has Micron components soldered down on it!