How physical addresses map to rows and banks in DRAM

[Mark Seaborn]

I wrote up another blog post related to rowhammer.  This one covers how physical addresses are mapped to row and bank numbers in DRAM, using one machine with a Sandy Bridge CPU as an example:

http://lackingrhoticity.blogspot.com/2015/05/how-physical-addresses-map-to-rows-and-banks.html

Cheers,

Mark

[davk...@gmail.com]

Hi Mark

Thanks for the excellent blog post (I've been looking into this too for some research I'm doing).

Just a question regarding your hypothesis re how the physical address maps to ranks/banks/rows/etc...

Did you just make assuptions for this and then check it out via the rowhammer tests or did you have some documentation about the memory controller for Sandy Bridge?

I'm trying to do something similar for an older system with a 1GB DDR2 module but as the memory isn't as dense I'm concerned that I wont really get any results by rowhammering (haven't tried this yet due to laziness :)).

My module is laid out as follows:

• 1 channel (1 module) = 0 bit idx
  
• 2 ranks = 1 bit index
  
• 4 banks = 2 bit index
  
• data bus width = 64 bit = 3 bit byte index
• 10 bit col address
• 14 bit row address
• == 30 bit = 1GB which matches memory module size

Any tips re working out the mapping? I could work it out logically if I had some sample data (like rowhammer) but alas I hath not. :)

[Mark Seaborn]

On 17 June 2015 at 00:45, <davk...@gmail.com> wrote:

Hi Mark

Thanks for the excellent blog post (I've been looking into this too for some research I'm doing).

Just a question regarding your hypothesis re how the physical address maps to ranks/banks/rows/etc...

Did you just make assuptions for this and then check it out via the rowhammer tests or did you have some documentation about the memory controller for Sandy Bridge?

It was the former.  I looked at the data from the rowhammer tests and tried to explain it based on physical address mappings I've seen described in various papers and in other docs for non-Sandy-Bridge systems.

I haven't got any documentation about the physical address mapping used by Sandy Bridge's memory controller.

The only Intel docs I've seen that cover memory controllers' mappings are fairly old.  For example:

"Intel E7501 Chipset Memory Controller Hub (MCH)", Datasheet, July 2003

http://www.intel.com/content/dam/doc/datasheet/e7501-chipset-memory-controller-hub-datasheet.pdf

-- see "5.5.3 Memory Address Translation and Decoding" and tables 5-3 and 5-4.

I actually tried to deduce the address mapping first for a rowhammer-vulnerable Ivy Bridge laptop, before I tried it for a Sandy Bridge laptop.  While I could fully explain the aggressor/victim address results I got on Sandy Bridge, I could only partially explain the results I got on Ivy Bridge.  I suspect there are extra complexities in Ivy Bridge's mapping that I haven't figured out yet.  The presentation at http://www.hotchips.org/wp-content/uploads/hc_archives/hc24/HC24-1-Microprocessor/HC24.28.117-HotChips_IvyBridge_Power_04.pdf hints at that.  Under "Uncore IPC Features", it says:

> * Channel Hashing -- DRAM channel selection mechanism

>   * Allows channel selection to be made based on multiple address bits

>   * Historically, it had been “A[6]”

>   * Allows more even distribution of memory accesses across channels

If you are interested, I can share the Ivy Bridge aggressor/victim address results.

 

I'm trying to do something similar for an older system with a 1GB DDR2 module but as the memory isn't as dense I'm concerned that I wont really get any results by rowhammering (haven't tried this yet due to laziness :)).

My module is laid out as follows:

• 1 channel (1 module) = 0 bit idx
  
• 2 ranks = 1 bit index
  
• 4 banks = 2 bit index
  
• data bus width = 64 bit = 3 bit byte index
• 10 bit col address
• 14 bit row address
• == 30 bit = 1GB which matches memory module size

Any tips re working out the mapping? I could work it out logically if I had some sample data (like rowhammer) but alas I hath not. :)

Two suggestions:

• What system is this, and what memory controller does it use?  The MCH link above shows that some memory controllers do have public documentation.
  
  
• You should be able to deduce the mapping by timing CLFLUSH'd memory accesses.  This is described in the paper "A Software Memory Partition Approach for Eliminating Bank-level Interference in Multicore Systems" (http://asg.ict.ac.cn/baoyg/downloads/PACT12-BPM.pdf).  See "Algorithm1" in the paper.
  
  I don't know of a publicly-available implementation of that algorithm, and I haven't tried implementing it myself yet.  However, I have tried timing CLFLUSH'd accesses between different address pairs, and I've observed the time differences caused by getting repeated row activations.
  
  I should really have mentioned that paper in my 4th May blog post under "Timing tests".  I came across that paper and the algorithm last year (it's cited by Yoongu Kim et al's rowhammer paper), but when I was writing up that blog post I tried to find where I had read about that algorithm and, at the time, I couldn't find it.  Unfortunately, PDFs of papers are not very Googlable!

Cheers,

Mark

On Thursday, May 7, 2015 at 8:29:07 PM UTC+3, Mark Seaborn wrote:

I wrote up another blog post related to rowhammer.  This one covers how physical addresses are mapped to row and bank numbers in DRAM, using one machine with a Sandy Bridge CPU as an example:

http://lackingrhoticity.blogspot.com/2015/05/how-physical-addresses-map-to-rows-and-banks.html

Cheers,

Mark

--
You received this message because you are subscribed to the Google Groups "rowhammer-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rowhammer-disc...@googlegroups.com.
To post to this group, send email to rowhamme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rowhammer-discuss/f2bf7809-14e5-4043-b678-29ee4a200ddd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthias Jung]

Dear Mark, 

Thank you for this nice blog post! Relating to that I want to mention my recent paper:

Reverse Engineering of DRAMs: Row Hammer with Crosshair

M. Jung, C. Rheinländer, C. Weis, N. Wehn.

International Symposium on Memory Systems (MEMSYS 2016), October, 2016, Washington, DC, USA.

Link: https://ems.eit.uni-kl.de/fileadmin/ems/pdf/38-final-acm.pdf

In this paper we present a technique that reconstructs the physical location of memory cells in a DRAM without opening the device package and micros coping the device. Our method consists of an retention error analysis while a temperature gradient is applied to the DRAM device. This enables the extraction of the exact neighborhood relation of each single DRAM cell.

Regards

Matthias

[pransh...@gmail.com]

Hey,

I am a senior undergraduate student of Electrical Engineering. In the course of doing an assignment for my course on Secure Memory Systems, I am trying to get this kind of data about my memory. Can I get a little guidance here? 

Moreover, we need to get the physical address mapping for our machine and stumbled upon this thread searching for methods to the same. Going through the discussion here, I see that the row hammer technique is the only one discussed here. Are there any other that you know of?

Thanks and Regards,

Pranshu Garg

[Dr.-Ing. Matthias Jung]

Not an easy way but it works ... Checkout here: https://doi.org/10.1145/2989081.2989114

--

You received this message because you are subscribed to the Google Groups "rowhammer-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rowhammer-disc...@googlegroups.com.
To post to this group, send email to rowhamme...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rowhammer-discuss/dda83e6a-c268-4e44-8dcc-ec2473734e5b%40googlegroups.com.

[David Kaplan]

A few years back I reverse engineered the mappings for older ddr2 on one of the Intel platforms by clocking it down as far as it would go (533mhz if memory serves) using a cheapish oscilloscope and multiple low bandwidth measurements.

I had code running on bare metal that basically flushed+prefetched on a loop.

Get Outlook for Android

---

From: rowhamme...@googlegroups.com <rowhamme...@googlegroups.com> on behalf of Dr.-Ing. Matthias Jung <jun...@eit.uni-kl.de>
Sent: Thursday, November 15, 2018 11:45:44 AM
To: pransh...@gmail.com; rowhammer-discuss
Subject: Re: [rowhammer-discuss] Re: How physical addresses map to rows and banks in DRAM

 

You received this message because you are subscribed to a topic in the Google Groups "rowhammer-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rowhammer-discuss/z82VBDqIdP8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rowhammer-disc...@googlegroups.com.

To post to this group, send email to rowhamme...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rowhammer-discuss/4595e5195fe54521f39f63b44683f902%40eit.uni-kl.de.

[lava joseph]

I have reverse engineered the Intel's ADL, TGL, RKL, CFL and AMD Ryzen series in full physical address range with Logic Analyzer. It is accurate, can resolve every channel/DIMM, BA, BG, row, column signal.

Actually, address mapping may vary among different mother boards even they have the same generation of CPU, and different mapping functions in different address scope.

[Patrick Jattke]

This sounds very interesting, although I cannot understand why the mainboard should matter if the CPU is the same.

Can you provide any more details about your results?

[lava joseph]

I'm not sure what is the root cause for it. Maybe BIOS on different MBs will set different address limit which have effect on address mapping.

we can see the last physical address varies among different MBs even with the same CPU and the same capacity of DRAM. 

You can input 'memmap' command on UEFI shell environment to see the memory map on system.