DRAM underclocking in lieu of ECC?

Hardware
1

I’m not at all convinced that Rowhammer and its legions of derivative attacks have been properly solved in general. A quick search of this forum has only reinforced that hypothesis.

It would be nice if we had a way (most likely in the firmware configuration) to underclock the DRAM by so-many percent (or even “a little” vs “not at all”) because Intel’s latest mobile CPUs don’t seem to support ECC (and haven’t for a long time).

The tradeoff between error rate and DRAM speed isn’t straightforward and surely varies by brand, SKU, and die lot, but better this than nothing. At best, errors decay exponentially with frequency, and in reality, probably as an inverse power law, which is pretty good news either way. It’s not about eliminating the possibility. It’s about making it so rare that an attacker can no longer induce bit flips under the time constraints of continuous attack. Fortunately, for that matter, multiprocessing doesn’t help much because such attacks are by definition memory-bound, so there’s no reason to restrict core counts.

Yes, some DRAM vendors have built mitigations into their hardware, but mitigations aren’t rigorous, by definition. Relying on physics instead of engineering would seem more robust.

Ironically, this slow-clock strategy might even increase performance per dollar because future models could use the cheapest garbage DRAM available, then underclock it a bit and end up with a secure solution that’s still admirably performant – as opposed to paying top dollar for mystical “Rowhammer mitigated” memory that runs at top frequency. (I don’t know Purism’s current vendor selection strategy in this regard, but I think it’s worth considering the tradeoffs here.)

Clearly the success of this strategy depends in part on the granularity with which one might downgrade the DRAM. Hopefully we could go from, say, 3.2 to 3.1 GHz, as opposed to 1.6 GHz.

I must emphasize that I’m not in favor of memory tests at boot time. They would accomplish little by way of detecting the vast array of possible runtime failures under thermal stress. They do, however, succeed in wasting an awful lot of time, which is why they had mostly died out many years ago.

2

@last para: I still have the pre-boot memory tests on my HP3000 minicomputer N-Class (can’t turn them off). They don’t flash by and stick at the top left corner like PCs do, they are displayed line by line. It was useful in telling you what card in which slot it went bad in order to replace them in. Booting is manual also. I have to enter “BOot” at the keyboard, or do something else. (I could configure it to autoboot, but I don’t.)

3

It’s not going to let you save cost and be more secure. If you lower the speed, in order to decrease the ram defect rate, then lower the quality of chips used, the ram defect rate will go back to where it was.

For any given quality of chip, I’m not sure that you’ll actually get a significant increase in security by dropping the clock speed. There is usually a point below which the chips have a very low error rate, and above which the defect rate exponentially increases. If you are below that point, dropping the ram speed will increase the time required for computations, which offsets the increased time needed to extract or set unapproved data.

4

You can determine whether the DRAM in the Librem 13/14/15/Mini is vulnerable by running the row hammer test available in MemTest86 v5.0 and later. It would be best to determine which Librem models/DRAM sticks are affected, so we don’t have to speculate.

Do you have a link to how underclocking can prevent row hammer? I haven’t heard of that working.

Evergreen will use Micron’s automotive-grade DRAM, so I’m not sure how that effects row hammer. The i.MX 8M Plus used in Fir will have support for DRAM inline ECC (although we don’t know if Purism will buy DRAM with inline ECC).

2 Likes
5

@amosbatto What do you mean by inline ECC? If it’s conventional DRAM ECC, it won’t work due to a lack of hardware support on the part of Intel CPUs. Also, has underclocking actually failed to mitigate Rowhammer in a dose-dependent manner? Logically, noise should drop as frequency drops because the DRAM’s eye diagram would get wider, affording more clearance between clock edges. Is Rowhammer not induced by a combination of noise and jitter?

@lperkins2 What I meant was that, given the choice between Brand A which is expensive because it’s essentially certain not to suffer from Rowhammer at its rated frequency, and Brand B which makes the same assertion but is much cheaper because it often fails anyway, I could choose Brand B and slightly underclock it, which should rapidly eliminate noise-induced cell failures, but allow me to save a lot of money. The result could well be acceptable security and more performance per dollar (not more aboslute performance).

6

The reference was to the Librem 5 (the phone) which has an ARM CPU.

7

Inline ECC uses the same bus lines as the data. First it sends the data, then it sends the ECC over the same bus lines. It is mostly used by the automotive industry. Because inline ECC doesn’t have separate ECC lines, it costs less than normal sideband ECC. The downside is that inline ECC sends less data than normal DRAM, because some of the time it is sending ECC over the data lines. See: https://www.synopsys.com/designware-ip/technical-bulletin/automotive-ddr-dram.html

I think you would have to run tests to verify if underclocking works to prevent row hammer. With some of the motherboards designed for overclocking, you can do tests. Unfortunately, motherboards on laptops are rarely designed to let you tweak RAM settings.

8

@amosbatto Inline ECC isn’t supported by any Intel chip to my knowledge. Google seems to agree, unfortunately. Perhaps that would work on ARM, but for laptops that leaves us with Xeons (an interesting option that sucks power, but not too much due to lower MHz) and underclocking. I would be fine with either, but Xeons would rock. (Might as well add some muscle since we’re already paying a premium for security features.) I can’t seem to find any research out there on DRAM underclocking for Rowhammer, and I’m personally not set up to do it. I bet the Purism hardware team could, though. It’s an important enough issue that it’s worth some effort.

@kieran Thanks for the clarification. I was talking about Librem laptops, but now that you mention it, this issue is also relevant to phones.

9

I installed the memtest86+ package in laptop, but when I rebooted and ran it from Grub, I found that it didn’t contain the row hammer test. Only the proprietary memtest86 has Test 13: Hammer, which is what you need. You can download it here:

I didn’t want to bother making a bootable USB, so instead I downloaded this code and ran it in normal user space:

I let it run 365 iterations on my Thinkpad T450s, without finding any row hammer problems, so I assume I’m protected. It would be nice if people who own Librem laptops would run it as well, and let us know their results and their particular models.

1 Like