In other words, blame Intel for trying to pass off ECC as a "Enterprise Feature" instead of the basic necessity that it is.
ECC is vulnerable to Rowhammer.
Row hammer is already super impractical. ECC does make the exploit harder.
Google says Rowhammer attacks are gaining range as RAM is getting denser
111–120 of 127 posts
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#112But while there are no known cases where Rowhammer attacks have been used in the real world Not on purpose but I'm sure that either it or phenomenon like it are the causes of a lot of odd "glitchy" behaviour that people encounter, because systems are run so close to their limits that there are bound to be cases when they surpass the limits. I remember many years ago discovering that a system which passed the CPU and…
The problem isn't RowHammer, the problem is lack of ECC. This is mostly Intel's fault, as they cripple their consumer CPU lines to disable ECC for market segmentation purposes. The entire premise that we can store tens of gigabytes of information reliably in tiny silicon capacitors without any error detection or correction whatsoever is ludicrous. Every other storage technology uses advanced error correction - NAND F…
I thought ECC wasn’t effective protection against Rowhammer? Agreed that it is incredibly useful otherwise. https://www.vusec.net/projects/eccploit/
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#113In other words, blame Intel for trying to pass off ECC as a "Enterprise Feature" instead of the basic necessity that it is.
Do you think many Ryzen PCs use ECC? I doubt that. It's accepted truth among gamers and power users, that ECC is waste of budget. I don't share this position, but if you'd ask on some computer forums, that's what you'll hear. If ECC would be enabled on all Intel CPUs, nothing fundamentally would change, most users would prefer to save 10% on their RAM.
Not sure about PCs, but my Ryzen laptop (HP EliteBook 835 G6) seems to use the AMD technology for memory encryption, with per-boot keys. This is not ECC, but also good enough to counteract RowHammer, because the attacker cannot target specific bits.
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#114What is the typical range of mean time to attack? Seconds?
Is it fair to model the attack as random coin flips (i.e., following a geometric distribution)?
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#1153
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#116Though ECC is a must in DDR5 spec. We still need a physical version of ASLR to mitigate this. Ideally, we can make Rowhammer even not practical for Denial of Service. For example, running a full-speed attack for an hour only has a 0.01% chance to flip a bit.
That's on-die error correction, DDR5 does not require ECC on the bus.
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#117But while there are no known cases where Rowhammer attacks have been used in the real world Not on purpose but I'm sure that either it or phenomenon like it are the causes of a lot of odd "glitchy" behaviour that people encounter, because systems are run so close to their limits that there are bound to be cases when they surpass the limits. I remember many years ago discovering that a system which passed the CPU and…
The problem isn't RowHammer, the problem is lack of ECC. This is mostly Intel's fault, as they cripple their consumer CPU lines to disable ECC for market segmentation purposes. The entire premise that we can store tens of gigabytes of information reliably in tiny silicon capacitors without any error detection or correction whatsoever is ludicrous. Every other storage technology uses advanced error correction - NAND F…
Doing ECC on-die (as in DDR5) does solve issues related to the storage itself, and the access timing of the array, but still leaves data vulnerable to corruption on the memory bus itself. Memory is indeed the only place were we are moving and storing data and it is commonplace to use zero layers of data protection; everywhere else we have at least one, often multiple, checksums and storage always has had forward error correction for a very long time, regardless of medium. But of course, generally speaking, all data processed by a computer moves through the main memory.
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#118Earlier quoted context omitted.
This article from Crucial probably explains the two arguments: https://www.crucial.com/articles/about-memory/difference-bet... But their conclusion is that practical latency has indeed decreased over the last 15 years.
After looking at the table, I am ready to swallow my pride. Looks like practical latencies have changed a tiny bit. So me and the person I replied to originally were both wrong
You were wrong about the memory latency¹ increasing, but the memory latency² has increased (substantially) for most systems, while the memory latency³ has indeed decreased. In general, the memory latency¹ has not improved much. Of course, the memory latency⁴ has greatly increased, due to the clock frequency being increased so much to enable the higher bandwidth, while the memory latency¹ stayed mostly the same.
[1] as in: access latency of the DRAM [2] as in: how long does a CPU memory read which is _not_ cached take [3] as in: how long does a CPU memory read on average take [4] as in: CL
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#119Earlier quoted context omitted.
> Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type? It's definitely possible in theory. You'd need four bit flips rather than three, so you'd probably need more time between accesses to the victim row, but thats a quantitative improvement at best. This can be mitigated by using different ECC bit encodings per memory location[0], so hammered data, with correct ECC for its row, always has wrong E…
We should be using memory encryption with random per-boot keys to prevent cold boot attacks, which would also solve the issue. Then the software doesn't know how its data maps to the encrypted data at the RAM. Rows may map 1:1, but you wouldn't know which bits you're targeting.
Good point. Although memory encryption is much more useful if applied at the CPU rather than the memory controler (which would need a way to turn encryption off for DMA regions, since the memory controller doesn't know the key), there's no actual reason why you couldn't do it in the memory controller, if you trust all the hardware with DMA access, or (more plausibly) trust the memory controller to limit that access properly.
Re: Google says Rowhammer attacks are gaining range as RAM is getting denser
#120Earlier quoted context omitted.
This article from Crucial probably explains the two arguments: https://www.crucial.com/articles/about-memory/difference-bet... But their conclusion is that practical latency has indeed decreased over the last 15 years.
After looking at the table, I am ready to swallow my pride. Looks like practical latencies have changed a tiny bit. So me and the person I replied to originally were both wrong
No, I was right. Not that it matters, feel free to replace latency with bandwidth. Or replace it with nothing and focus on capacity. It's a blip on my point, which is that the architecture has changed considerably to allow for progress in other areas.