4 ms·
Does this finally address Rowhammer? Ctrl-F on the article yields nothing...
by luizfelberti 6y ago
Does this finally address Rowhammer? Ctrl-F on the article yields nothing...
- kube-system 6y agoThat's more of a die-level issue rather than a module-level issue, isn't it?
- dfox 6y agoDDRwhatever 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.
- O5vYtytb 6y agoPossibly with on-die ECC.
- DoctorOetker 6y agodoes 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
- stefan_ 6y agoRowhammer can be eliminated through RAM encryption, e.g. (Transparent) Secure Memory Encryption in Ryzen processors.
- nullc 6y agoHow 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.
- duskwuff 6y agoWith 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.
- nullc 6y agoDoesn'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. :)
- duskwuff 6y agoThe 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.