Apple EFI patch to mitigate row hammer

[yst...@gmail.com]

1. Apple increases the memory refresh rate to mitigate the row hammer. [i]

This works because 

a) less time to hammer

b) less time for a cell to leak charge

However [ii] describes that bit flips occur even with refresh occurring even at 16 ms intervals.

This forces the question - how much did Apple lower the time between refreshes?

 

2. Refresh comes at a penalty[1]

Does anybody have any standardized meassurements of the price apple is paying in terms of performance?

 

3. Power consumption

If I understand it correctly a refresh is not only expensive in terms of tRFC time, but also in power consumption. Would their solution be heat/battery life relevant in real life scenarios?

Best regards,

Anders 

---

[i] https://support.apple.com/en-us/HT204934

[ii] http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf 

 

[Mark Seaborn]

On 2 July 2015 at 02:46, <yst...@gmail.com> wrote:

1. Apple increases the memory refresh rate to mitigate the row hammer. [i]

This works because 

a) less time to hammer

b) less time for a cell to leak charge

However [ii] describes that bit flips occur even with refresh occurring even at 16 ms intervals.

This forces the question - how much did Apple lower the time between refreshes?

I am working on a tool that can measure the DRAM refresh rate and so answer questions like that.  It works by timing CLFLUSH'd memory accesses and observing the delays that occur during refreshes.

The code is here:

https://github.com/google/rowhammer-test/tree/master/refresh_timing

My guess would be that Apple doubled the refresh rate, changing from a 64ms refresh period to a 32ms refresh period.

 

2. Refresh comes at a penalty[1]

Does anybody have any standardized meassurements of the price apple is paying in terms of performance?

Wikipedia says "Although refresh overhead occupied up to 10% of chip time in earlier DRAMs, in modern chips this fraction is less than 1%" (https://en.wikipedia.org/wiki/Memory_refresh).

This blog post is better for explaining the background:  http://utaharch.blogspot.com/2013/11/a-dram-refresh-tutorial.html

Here's a rough estimate based on experiment:

On an example (non-Apple) laptop, with a 64ms refresh period, DRAM accesses are normally ~80ns but slow down to ~250ns every 7812.5ns.  So refreshes mean that DRAM is unavailable for around (250 - 80) / 7812.5 = 2.2% of the time.  Doubling the refresh rate would make DRAM unavailable for 4.4% of the time.

Those memory access times match up with what decode-dimms reports for the DRAM's tRFC value on that laptop:

---=== Timing Parameters ===---

Minimum Write Recovery time (tWR)               15.000 ns

Minimum Row Active to Row Active Delay (tRRD)   6.000 ns

Minimum Active to Auto-Refresh Delay (tRC)      49.125 ns

Minimum Recovery Delay (tRFC)                   160.000 ns

Minimum Write to Read CMD Delay (tWTR)          7.500 ns

Minimum Read to Pre-charge CMD Delay (tRTP)     7.500 ns

Minimum Four Activate Window Delay (tFAW)       30.000 ns

 

3. Power consumption

If I understand it correctly a refresh is not only expensive in terms of tRFC time, but also in power consumption. Would their solution be heat/battery life relevant in real life scenarios?

I expect there are studies but I don't know any to cite.  It should be possible to measure this experimentally by measuring power consumption before and after a BIOS/EFI update.

By the way, when a laptop is suspended, DRAM refresh is probably one of the main consumers of power.  Note that if a laptop is using 2x refresh to mitigate rowhammer, 1x refresh would still be fine when a laptop is suspended and no code can execute.  I wonder if any vendors implement switching from 2x to 1x refresh in suspend mode.

Cheers,

Mark

[Mark Seaborn]

On this topic, I have compiled a list of vendor responses to the rowhammer problem that I know of:

https://github.com/google/rowhammer-test/blob/master/docs/vendor_responses.md

If you know of any others, please let me know and I'll add them to the list.

Cheers,

Mark

On 2 July 2015 at 02:46, <yst...@gmail.com> wrote:

--
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/c9e42c50-6678-4574-9b13-14236352194c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.