We already have error correction detection available to us and it's in use today.
> RAM should always hold what was last written to it, under all conditions of software accesses.
OK? That's what anyone who is advocating for ECC is already advocating for. ECC is error correcting up to 1 bit and error detecting up to 2 bits. The goal is to ensure that the property you've described holds.
> It only got created because the RAM companies have forsaken correctness,
This problem exists because... physics. Do you actually have a design for RAM that can match today's cell density while somehow providing perfect isolation? Saying this problem didn't exist 15 years ago is like saying that malware didn't impact the abacus - RAM 15 years ago was designed completely differently, and had considerably lower capabilities in terms of storage and latency.
And for reference, hamming codes (which back ECC) were created in the 1950s for error correction in punch cards. This is not a new problem.
ECC is the existing, obvious solution to this problem, it just wasn't built for this threat - but it's an excellent, proven method for correcting bit flips. Even without being designed to prevent rowhammer it already makes the attack much slower, less likely to succeed, and easier to detect (just monitor for a massive spike in ecc corrections).
Trying to design high density RAM that maintains perfect isolation seems pointless. Improving ECC or ECC-like approaches is likely going to be much more effective.
You got that backwards, chief. RAM latencies have increased tremendously over the last 15 years.
[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
I don't know about that. Rowhammer really emphasizes the hammer. A normal read pattern will basically never hit the lines in a small area that much, it will hit cache instead.
> Now you've turned specific access patterns into "attack attempts", and by discriminating against them as such, entirely destroyed a fundamental part of general-purpose computing.
Can you show me any code that causes this kind of access pattern that wasn't deliberately designed to implement rowhammer?
> Where manufacturers are trying to sell 2-4x the capacity with 1/4 to 1/16th of the endurance?
We could go the other way too and glue together multiple SLC cells to increase endurance and cost. Are you claiming there is a specific correct amount of endurance? Because "as much as possible" isn't feasible and "as much as SLC used to have" could only be correct from an extreme coincidence or from conflating nostalgia with correctness. Is there a different number you have in mind?
> This problem didn't exist 15 years ago. It only got created because the RAM companies have forsaken correctness, and somehow managed to convince everyone else that it's not their own fault.
Old ram had errors too. RAM companies can and should put in mechanisms to prevent rowhammer, but if I was buying a stick of ram and had a choice between ECC and perfect rowhammer prevention I'd choose ECC.
No, ECC is there to correct any errors, including normal errors that occur during operation. It allows us to build technologies that have a much higher raw channel error rate, and decrease the system error rate to better than before. In return, we get much higher density, performance, or whatever other metric you want to optimize for.
This is basic information theory. It is extremely inefficient to attempt to build a channel with a low enough raw bit error rate to be usable. Instead we let the bit error rate rise, then correct the errors with error correction codes. This reduces the bandwidth, proportional to error rate for advanced error correction, which is still a negligible amount compared to the total channel bandwidth - the performance improvements from allowing the raw error rate to rise more than make up for this, and result in orders of magnitude better performance.
> Now you've turned specific access patterns into "attack attempts"
Ever heard of files you can't burn on CD-R, or transmit through certain variants of Ethernet? We use technologies that are probabilistic all the time; they assume data is not correlated with a pseudorandom internal characteristic of some sort. These files only exist because someone explicitly targeted them; the chances of someone stumbling onto such data randomly are basically nonexistent (for any well designed system).
That said, this can be mitigated without throwing ECC out the window.
> RAM should always hold what was last written to it, under all conditions of software accesses.
And it will, after ECC. Why are you drawing an arbitrary line for RAM and saying it can't use ECC? Are you also against HDDs (LDPC error correction), Wi-Fi (convolutional codes), NAND storage of all kinds (increasingly advanced ECC), USB (error detection and re-transmission), TCP (error detection and re-transmission), the internet as a whole (flow control by dropping packets), CDs (three layers of error correction for data!), Bluetooth (FEC and/or ARQ), Digital TV (ATSC, DVB, ISDB all use FEC of some kind), QR codes (reed-solomon), and even things like RAID6? The people who designed these systems aren't dumb, they know the only way to get performance and reliability is to use error correction.
It's a damn miracle we get away with non-ECC RAM, today. That stuff should've died 20 years ago, and ECC should be standard. Even the caches inside CPUs often have ECC these days.
> Where manufacturers are trying to sell 2-4x the capacity with 1/4 to 1/16th of the endurance? That's a rant for another thread...
Yes, manufacturers having a race for the bottom to achieve the highest capacity at the expense of all reliability and performance metrics is a completely different problem that doesn't mean we need to throw ECC out the window, which would also hurt all of those metrics. Optimizing for endurance and performance still requires ECC.
The solution is simple: don't buy QLC flash. That stuff's garbage, at least today.
Or would you prefer to go back to the era of 16MB CompactFlash cards (that's MB) using SLC NOR Flash? That stuff doesn't need ECC, certainly, and the endurance is amazing. Let me know how the cost per gigabyte and write performance metrics work out in your NOR world, though :-)
Or perhaps you'd rather have us store all of our data on 16KB EEPROM chips, with even better endurance! I'm sure nobody will mind the 1KB/s write performance (if you're lucky). Maybe if you RAID a few thousand of those it'll work! Oh wait, then random errors will kill your data anyway, without something like RAID-6. Oops!
> This problem didn't exist 15 years ago.
15 years ago the average computer had 256MB of RAM. I had one of those. And I had a bad RAM bit back then, which I had to mask out with a kernel patch (that I had to port from x86 to amd64, as I was an early adopter of 64-bit), which would've been a non-issue with ECC RAM.
I know about weak sectors. Only shitty (i.e. defective by design) drives wouldn't be able to handle them, while others would do it just fine.
Why are you drawing an arbitrary line for RAM and saying it can't use ECC?
I'm not saying that ECC is not a good idea. I'm saying that ECC errors in RAM occurring simply because of specific access patterns is far from "normal operation". In fact, if you use ECC RAM and see a lot of errors, it should be considered a sign of failing hardware. In other words, advocating for ECC in this scenario is deflecting the blame and compensating for a defective product.
The solution is simple: don't buy QLC flash. That stuff's garbage, at least today
"QLC" and "TLC" are complete misnomers developed specifically to hide the truth. It's not 4 or 3 "levels", but 16 and 8, respectively. 16LC and 8LC are the technically correct terms.
Corporate greed has somehow resulted in everyone parroting the dominant industry position and using Intel and ECC as a scapegoat. That just shows how entrenched their propaganda is.
I know what those terms mean. I find it amusing that you'd think I don't, given I just rattled off the ECC types used by a dozen technologies and mentioned 3 different kinds of nonvolatile charge trap memory.
Plus you can detect attack attempts as the memory controller will report increased error rates.
Now you've turned specific access patterns into "attack attempts", and by discriminating against them as such, entirely destroyed a fundamental part of general-purpose computing. What's next, CPUs that are only guaranteed to do certain operations correctly, and everything else is considered an "attack"? That is NOT a direction that we should be heading. Hell fucking no!!!
RAM should always hold what was last written to it, under all conditions of software accesses. To expect or imply that anything less is acceptable, is to destroy one of the foundations on which general-purpose computing is built.
NAND Flash
Where manufacturers are trying to sell 2-4x the capacity with 1/4 to 1/16th of the endurance? That's a rant for another thread...
We know how to solve this problem.
This problem didn't exist 15 years ago. It only got created because the RAM companies have forsaken correctness, and somehow managed to convince everyone else that it's not their own fault.