Hacker News Reader

Comment by luizfelberti | Hacker News Reader

Does this finally address Rowhammer? Ctrl-F on the article yields nothing...

That's more of a die-level issue rather than a module-level issue, isn't it?

DDRwhatever is primarily an definition of package level interconnect which has possibility of being used as module level interconnect as one of design constraints. And row hammer and similar things are completely irrelevant for such specifications.

Possibly with on-die ECC.

does current hardware and software already allow keeping counts of detected and corrected ECC errors? is it possible for the OS to attribute it to a specific process?

if so it seems like OS'es could track and publically tell on executables

Rowhammer can be eliminated through RAM encryption, e.g. (Transparent) Secure Memory Encryption in Ryzen processors.

How does encryption help? When you only need to achieve a 1-bit change it doesn't matter much if the exact change isn't predictable.

With any sort of decent encryption, flipping a bit will corrupt the entire cache line unpredictably. That's still bad, of course, but it's much less likely to be exploitable.

Doesn't really much help if all the attack is needs to do is flip a flag or replace a value with one that evaluates to true (e.g. anything except 0).

Sure, any particular exploit may be less likely to work, but once you can hammer memory 3/4 of the code running on the system turns into a potential exploit vector. :)

The problem is collateral damage. It's rare that writing garbage to an entire 64-byte (not bit!) cache line will go unnoticed -- in most applications, chances are good that there'll be at least one pointer in there that'll be corrupted.

Reply on news.ycombinator.com