LWN: Comments on "Exploiting the DRAM rowhammer bug to gain kernel privileges"

Exploiting the DRAM rowhammer bug to gain kernel privileges

ibukanov — Sat, 14 Mar 2015 18:05:45 +0000

> ECC only serves to reduce probability of unnoticed corruption

According to the table 5 in [3] there are memory modules where probability of a triple error per 64-bit word that SECDED memory cannot detect is 2248/(2GB/8) or 1e-5. So in principle ECC memory indeed cannot protect against the errors. However, even if the same buggy memory technology is used for ECC chips, it is not clear how practical that exploit could be as one needs for the bug to happen in memory cells holding page tables or other exploitable locations before ECC halts the system due to uncorrectable double errors or too many single errors.

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

Exploiting the DRAM rowhammer bug to gain kernel privileges

xorbe — Thu, 12 Mar 2015 18:30:31 +0000

Yeah, that was the original conjecture. Looks like someone figured out how to do it!

Exploiting the DRAM rowhammer bug to gain kernel privileges

deepfire — Thu, 12 Mar 2015 16:03:42 +0000

Suppose we have two options: 1) decrease DRAM refresh period, and 2) add ECC.

There are two interesting lenses to see that through: security and power efficiency.

From the security angle, it seems that ECC only serves to reduce probability of unnoticed corruption, since it doesn't eliminate the underlying cause and ECC is an inherently probabilistic tool (and also designed for a cosmic ray fault scenario, so of reduced applicability).

The reliability of DRAM refresh period tweaks, on the other hand, is much harder to evaluate, since it heavily depends on the physical properties of the cells. At least there are hints that it can be effective enough so as to make the attack impractical.

But this breeds a new uncertainty.. since the attack scenario is so relatively easy -- what are the boundaries of "impracticality"? How do we reassure ourselves we pushed beyond them?

As to power efficiency.. it's similarly moot, and seems to depend on the physical properties and on the unknown (to me) power consumption delta incurred by ECC.

The question is how the DRAM manufacturer industry will react.

How transparent will that be? Will that lead to industry-wide benchmarks on row-hammering?

Exploiting the DRAM rowhammer bug to gain kernel privileges

lopgok — Wed, 11 Mar 2015 19:15:49 +0000

I don't think that SODIMMs have access to magic chips using a smaller process size than standard sized DIMMs. DRAM are commodity parts. Companies will generally use the latest generation parts on their memory modules, no matter if they are SODIMMs or standard sized DIMMS.

As for operating the parts out of spec, no reputable company would do that, though I can't speak for every company. If I found a DIMM maker running the parts out of spec for voltage or refresh rate, I would return it right away. I know some 'overclock' the parts by running them at a higher voltage and frequency, but those parts are advertised as doing that.

As for the price margins being lower for SODIMMs than DIMMs, I am aware of no evidence to support that.

As for low power, there is a big market for low power DIMMS for servers, generally known as LPDIMMs.

My several year old server motherboard can accept LPDIMMs or standard voltage DIMMS depending on the xeon processor used. And my DDR3 DIMMS are 16gb each. (My memory is Hynix. I recommend buying reputable companies memory if possible.) I don't know of any SODIMMs that are that big.

It would be interesting to know the specific notebooks involved as well as the specific SODIMMs. I don't think hiding the manufacturers serves the general public. If there are more vulnerable specific parts, it would be a benefit to know what they are.

Exploiting the DRAM rowhammer bug to gain kernel privileges

flussence — Wed, 11 Mar 2015 18:08:17 +0000

I've been running rowhammer_test for the past hour on a mini-ITX desktop with DDR3-1600 SODIMMs (non-ECC). No idea how long I should wait to expect any result, but this hardware seems reasonably stable. As it should be, it wasn't cheap!

(The news only mentions DDR3/4, does that mean all my other systems on DDR2 are safe?)

Exploiting the DRAM rowhammer bug to gain kernel privileges

NRArnot — Wed, 11 Mar 2015 16:32:37 +0000

SODIMM vs DIMM: it's not directly related. However, SODIMMs are smaller so may be using smaller chips (smaller process sizes) to pack the same amount od RAM onto less PCB area.

Also, Laptops are judged by their battery life. Two ways to reduce power consumption are to lower the DRAM operating voltage, and to lower the DRAM refresh frequency. Have laptop manufacturers and manufacturers of DRAM for laptops been pushing the envelope too aggressively? In contrast, there's much less pressure on desktop systems to save fractions of a watt.

Also, margins on laptops are wafer-thin. Have the same pressures that gave rise to an epidemic of factory-installed malware, also resulted in the use of the cheapest DRAM that money can buy?

It'll be interesting to probe this further. Is the primary influence the memory module itself, or what it is plugged into? Are some brands better than others? Does cheapest imply worst? (Implying that someone knew something, but shipped it anyway)? And so on.

Exploiting the DRAM rowhammer bug to gain kernel privileges

barryascott — Wed, 11 Mar 2015 16:03:47 +0000

There is section on "Mitigations" in the blog post including one of your suggestions with analysis.

Exploiting the DRAM rowhammer bug to gain kernel privileges

lopgok — Wed, 11 Mar 2015 14:32:50 +0000

I doubt this has anything to do with SODIMM vs DIMM. That is just the circuit board the RAM is packaged on. Some desktops (like mine) have ECC, however no notebooks as far as I know have ECC. IIRC long ago there was a SPARC based notebook that had ECC memory. Somewhere around 15 years ago. I don't think any notebook since has had ECC memory. As the individual dies for memory increase in density, the possibility of rowhammering due to depleted charge goes up.

Clearly the refresh rate was designed for 'reasonable' memory accesses, but some refresh rates are too low for pathological memory accesses, resulting in the vulnerability.

Exploiting the DRAM rowhammer bug to gain kernel privileges

nhippi — Wed, 11 Mar 2015 07:06:14 +0000

With the mean price competition in cloud/vps hosting, I'm sure some providers cut corners by using non-ECC memory. People must be already running rowhammmer-test on cloud servers, so we will hear soon...

Exploiting the DRAM rowhammer bug to gain kernel privileges

lkundrak — Wed, 11 Mar 2015 05:52:23 +0000

Haha, instant classic :)

Exploiting the DRAM rowhammer bug to gain kernel privileges

Duncan — Wed, 11 Mar 2015 01:43:52 +0000

Fortunately, if you read the report (and as the Register story that I read on this a few hours ago mentioned, the short excerpt here was simply too small to catch that angle so only those reading the full article or see it in the comments will catch it), it was generally newer laptops with DDR3/DDR4 RAM that had the problem -- they couldn't get desktops to trigger.

Servers aren't really mentioned (at least that I saw in my quick skim), but they did say the desktops were higher end and at least some of them had ECC RAM, which they speculated was what prevented the problem there.

What the Register comments suggested, however, is that it's not just ECC, tho that should in theory be nearly bulletproof against this type of problem, but that it may also be the smaller SODIMM technology at fault here, vs the normal-profile DIMMs generally used in "full-size" desktop and server applications.

So servers using standard-profile ECC DIMMs are unlikely to be easily attacked, at least in the current DDR3/DDR4 generations. In theory as features miniaturize, it could become a problem, at least for non-ECC, but now that the threat is known and published, it's less likely.

Duncan

Exploiting the DRAM rowhammer bug to gain kernel privileges

rodgerd — Wed, 11 Mar 2015 00:28:13 +0000

This could be particularly disturbing on public cloud/virtual hosting environments if the technique can be extended to attacking other VMs.

Exploiting the DRAM rowhammer bug to gain kernel privileges

cesarb — Tue, 10 Mar 2015 23:51:39 +0000

Could the Linux kernel reprogram the memory controller to decrease the refresh interval?

If not, would it be possible to make use of the performance counters to trigger an interrupt in case of excessive cache misses, pausing for a few ms on the interrupt to give the refresh counter time to catch up?

Exploiting the DRAM rowhammer bug to gain kernel privileges

Jonno — Tue, 10 Mar 2015 23:16:44 +0000

> As I recall, this is basically impossible to exploit due to the effect of caches.

No, if you read the article it contains two working proof-of-concepts using a cache-flush op, and speculates about the possible use other of cache-bypassing ops.

Exploiting the DRAM rowhammer bug to gain kernel privileges

xorbe — Tue, 10 Mar 2015 23:06:53 +0000

As I recall, this is basically impossible to exploit due to the effect of caches.

Exploiting the DRAM rowhammer bug to gain kernel privileges

makomk — Tue, 10 Mar 2015 22:39:16 +0000

Apparently it's possible to work around the issue in the controller though. There's a full explanation in the original paper, but basically they reckon that randomly refreshing the neighbouring rows after a very small but non-zero proportion of memory accesses will make it infeasible to trigger the bug without affecting performance.

Exploiting the DRAM rowhammer bug to gain kernel privileges

jgg — Tue, 10 Mar 2015 22:39:15 +0000

The DRAM is the source of the bit flip, but it is not the root problem.

Loss of DRAM charge is expected, it is how the technology works. Refresh has been an integral part of DRAM since the beginning.

The issue is that the DRAM is not being refreshed enough to counter the coupled charge change from this particular access pattern.

It appears that DRAM suppliers have under-estimated the refresh period that is required, and haven't fully appreciated the impact on over-activation on neighbouring-row charge.

All of the mitigations for this problem revolve around changes to the controller to generate more refresh cycles, to limit the number of same row activations, and/or additional logic smarts in the on-die controller to generate more refreshes.

Until smarter controllers are designed, the only response is to double (or more) the refresh frequency in the controller, and accept the performance lossage. This can be done with a BIOS update.

Exploiting the DRAM rowhammer bug to gain kernel privileges

JoeF — Tue, 10 Mar 2015 22:34:17 +0000

I remember that current leaking to the next row has always been an issue in DRAMs, but the tight packing of modern chips apparently makes it exploitable now.
An interesting side-effect of Moore's law...

Exploiting the DRAM rowhammer bug to gain kernel privileges

xnox — Tue, 10 Mar 2015 22:17:36 +0000

How many linux kernel engineers are needed to fix rowhammer?
None, it's a hardware problem.

Exploiting the DRAM rowhammer bug to gain kernel privileges

galah — Tue, 10 Mar 2015 22:03:21 +0000

This is a problem in the DRAM, not the controller.

Exploiting the DRAM rowhammer bug to gain kernel privileges

landley — Tue, 10 Mar 2015 21:56:51 +0000

To fix this, do you have to replace just the memory, or the whole DRAM controller?