ECC isn't really the golden solution. It will likely just turn rowhammer into a DoS instead of something which is exploitable (and even with ECC it can still be exploitable just harder). While this is an improvement I wouldn't call it a golden solution.

A DoS from a program already running on the same hardware is nowhere near the same level of vulnerability as a privilege escalation.

Security is all about increasing those difficulty thresholds, not absolutes.

I agree, the only thing I was really taking issue with is calling it a "golden solution". When in fact it is just a (useful) mitigation.

TRR might better fit the description of a "golden solution" although it is still technically a mitigation. I would very much like to see more ECC in consumer/desktop systems.

I agree as I also found the lack of transition of ECC into consumer level pricing and hardware a lamentable state.

Now with these public issues becoming more open, one can only hope that some consumer product moves to ECC and ends up driving ECC memory prices down in much the same way as mobile phones have driven many sensors and associated hardware down in price, thru volume.

I mean, with ECC memory you need to cause 3 bit flips for it to turn into an exploit. 1 bit flipped pew row is recoverable, 2 will cause a detectable fault, and from what I've seen on rowhammer so far getting past that is going to be pretty difficult.

Your right, my bad and it is more case of it being the best solution to date.

If you can change the hardware then the best solution is TRR, which should completely eliminate bit flips due to rowhammer. This doesn't do anything for the millions(?) of vulnerable systems in the wild.

What is TRR?

Targeted Row Refresh - a DRAM command which the memory controller can issue to refresh rows adjacent to heavily used rows and prevent corruption.