3 ms·

Is ECC memory vulnerable to these kinds of bitflips?

codetrotter 3y ago
The paper has some mentions of ECC. https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf For example, the first mention of ECC says this: > we ensure that the tested DRAM modules and chips have neither rank-level nor on-die ECC. Doing so ensures that we directly observe and analyze all circuit-level bitflips without interference from architecture-level correction and mitigation mechanisms. Later in the paper they say: > We examine the capability of ECC, which is widely used in modern memory systems to correct memory errors, in mitigating Row Press. We analyze the number of bitflips in every 64-bit word for both single- and double-sided RowPress for a tAggON of 7.8 Ms. To maximize the number of bitflips at this tAggON, we activate the aggressor row(s) as many times as possible within 60 ms at 80°C. […] > We make two key observations from our analysis. First, there are up to 25 Row Press bitflips (not shown) in a 64-bit data word. ECC schemes that are widely used in memory systems (e.g., SECDED [122] and Chipkill [123-125\23) cannot correct or detect all RowPress bitflips we observe, which can lead to silent data corruption [126- 128]. Even a (7, 4) Hamming code (correcting one bitflip in a 4-bit data word) [122] with 75% DRAM storage overhead (3 parity bits for every 4 data bits), is not capable of correcting 25 bitflips in a 64-bit data word. Other ECC schemes that can correct all Row Press bitflips require prohibitively large storage overheads. Thus, relying on ECC alone to prevent all RowPress bitflips is a very expensive solution. Second, for all three manufacturers (Mfrs. A, B, and C), a significant fraction (up to 0.99%, 35.77%, and 10.08% for tAggON = 7.8 us, respectively) of 64-bit data words exhibit at least three Row-Press bitflips. This makes RowPress bitflips costly to prevent using techniques like memory page retirement (where erroneous DRAM rows are not used in the system) [129, 130] since such techniques could render up to 35.77% of storage capacity useless.
- exmadscientist 3y ago
  What a thoroughly disingenuous argument they make. Let me rephrase that in terms of adventures trying to break in to the castle throne room. They say that if you keep sending a million adventuring parties, eventually some will break in, perhaps as many as 25 adventurers at once and there's no way you can afford 25 guards 24/7 to protect anything. The obvious counter-argument is that, sure, maybe the millionth party will get in... but someone had to notice the guards stopping the first 999,999 failures, right? That counts for something? Most "defeats" of ECC in these RowHammer style attacks are of this form, and are not in my opinion actually defeats. Authors are just sleazily handwaving away the ECC to get a sexier paper. (ECC with OS error reporting is like having posted guards with someone supervising. If this analogy makes you wonder how things can possibly work without any ECC/guards, congratulations, you see the argument the ECC-everywhere camp are making!)
Palomides 3y ago
ECC is very resistant but not immune, but at least it will let you detect rowhammer attacks
- adrian_b 3y ago
  Yes, the advantage of ECC against RowHammer or RowPress attacks is detection, not prevention. The attacks usually produce more bit flips than can be corrected by ECC, but the attacker cannot control the number and the position of the bit flips. When a memory uses ECC (true end-to-end ECC, not the internal ECC of DDR5, which is useless against these attacks, because the errors are not reported to the OS), there are many more invalid memory bit configurations, than valid ones. Because of this, applying a random pattern of bit flips to the memory is much more likely to be detected as an ECC error, than to be ignored. Computers with ECC are normally configured to scrub all the memory periodically, so the bit flips caused by an attack will be detected even in unused memory. Because in a normal computer it is extremely unlikely to encounter more than one ECC error per day (either correctable or non-correctable), a decent operating system should immediately notify the user or the administrator in the case of repeated errors, which can appear only as a consequence of a hardware malfunction or of a RowHammer/RowPress attack (many servers are configured to send immediately an e-mail message or an SMS alert to the administrator when such events happen). Therefore, on computers with ECC it should be impossible for such attacks to remain undetected, even if they can succeed to corrupt the memory.

The paper has some mentions of ECC. https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf For example, the first mention of ECC says this: > we ensure that the tested DRAM modules and chips have neither rank-level nor on-die ECC. Doing so ensures that we directly observe and analyze all circuit-level bitflips without interference from architecture-level correction and mitigation mechanisms. Later in the paper they say: > We examine the capability of ECC, which is widely used in modern memory systems to correct memory errors, in mitigating Row Press. We analyze the number of bitflips in every 64-bit word for both single- and double-sided RowPress for a tAggON of 7.8 Ms. To maximize the number of bitflips at this tAggON, we activate the aggressor row(s) as many times as possible within 60 ms at 80°C. […] > We make two key observations from our analysis. First, there are up to 25 Row Press bitflips (not shown) in a 64-bit data word. ECC schemes that are widely used in memory systems (e.g., SECDED [122] and Chipkill [123-125\23) cannot correct or detect all RowPress bitflips we observe, which can lead to silent data corruption [126- 128]. Even a (7, 4) Hamming code (correcting one bitflip in a 4-bit data word) [122] with 75% DRAM storage overhead (3 parity bits for every 4 data bits), is not capable of correcting 25 bitflips in a 64-bit data word. Other ECC schemes that can correct all Row Press bitflips require prohibitively large storage overheads. Thus, relying on ECC alone to prevent all RowPress bitflips is a very expensive solution. Second, for all three manufacturers (Mfrs. A, B, and C), a significant fraction (up to 0.99%, 35.77%, and 10.08% for tAggON = 7.8 us, respectively) of 64-bit data words exhibit at least three Row-Press bitflips. This makes RowPress bitflips costly to prevent using techniques like memory page retirement (where erroneous DRAM rows are not used in the system) [129, 130] since such techniques could render up to 35.77% of storage capacity useless.

exmadscientist 3y ago
What a thoroughly disingenuous argument they make. Let me rephrase that in terms of adventures trying to break in to the castle throne room. They say that if you keep sending a million adventuring parties, eventually some will break in, perhaps as many as 25 adventurers at once and there's no way you can afford 25 guards 24/7 to protect anything. The obvious counter-argument is that, sure, maybe the millionth party will get in... but someone had to notice the guards stopping the first 999,999 failures, right? That counts for something? Most "defeats" of ECC in these RowHammer style attacks are of this form, and are not in my opinion actually defeats. Authors are just sleazily handwaving away the ECC to get a sexier paper. (ECC with OS error reporting is like having posted guards with someone supervising. If this analogy makes you wonder how things can possibly work without any ECC/guards, congratulations, you see the argument the ECC-everywhere camp are making!)

Palomides 3y ago

ECC is very resistant but not immune, but at least it will let you detect rowhammer attacks

adrian_b 3y ago
Yes, the advantage of ECC against RowHammer or RowPress attacks is detection, not prevention. The attacks usually produce more bit flips than can be corrected by ECC, but the attacker cannot control the number and the position of the bit flips. When a memory uses ECC (true end-to-end ECC, not the internal ECC of DDR5, which is useless against these attacks, because the errors are not reported to the OS), there are many more invalid memory bit configurations, than valid ones. Because of this, applying a random pattern of bit flips to the memory is much more likely to be detected as an ECC error, than to be ignored. Computers with ECC are normally configured to scrub all the memory periodically, so the bit flips caused by an attack will be detected even in unused memory. Because in a normal computer it is extremely unlikely to encounter more than one ECC error per day (either correctable or non-correctable), a decent operating system should immediately notify the user or the administrator in the case of repeated errors, which can appear only as a consequence of a hardware malfunction or of a RowHammer/RowPress attack (many servers are configured to send immediately an e-mail message or an SMS alert to the administrator when such events happen). Therefore, on computers with ECC it should be impossible for such attacks to remain undetected, even if they can succeed to corrupt the memory.