Hacker News new | past | comments | ask | show | jobs | submit login

From the blog--

>> This is likely an indication that the electrical coupling responsible for Rowhammer is a property of distance, effectively becoming stronger and longer-ranged as cell geometries shrink down

From the paper (bottom of page 13)--

>> ... we saw mappings from [1] that we used for this work. This suggests that the published findings about distance >1 Rowhammer are simply a result of not taking the correct mapping into account. Given that the patters we found appear to be distance 2 attacks, our industry partners were skeptical about them.

These bits tell a much bigger story to me. It's interesting that both the researchers and "industry partners" had this slip under their nose.

Part of it might be, as Google claims, shrinking cell sizes. Whereas previous > distance 1 attacks were purely hypothetical, or at least too noisy, as even the researchers note that double-sided was far more reliable [1], times have apparently changed since 2018, which itself is an interesting hypothesis. Kinda like with crypto [2], what's old may become new again.

TRR (for all its faults [3]) still provided some mitigation, as Google notes, but apparently only against distance-1 attacks.

The other part is-- Verification wise, it's not difficult to scale verifying TRR's security properties, so part of me is surprised that the "industry partners were skeptical about [distance-2 attacks]".

You would imagine that a robust verification environment would do a little more due-diligence when checking Rowhammer mitigations. Assuming you *have* a verification environment, which I also realize is a tall order :)

Of course, I realize the initial mitigations were already costly. I'm not saying the solution should have been more TRR-- I'm saying that proper security testing should have at minimum detected distance-N attacks.

Of course^2, hindsight is always easy.

[1] https://download.vusec.net/papers/hammertime_raid18.pdf

[2] https://en.wikipedia.org/wiki/ROCA_vulnerability

[3] https://arxiv.org/pdf/2004.01807.pdf




> I'm not saying the solution should have been more TRR

Might as well add it. Even ignoring the fact that TRR will basically never trigger on non-malicious code, if it takes thousands of accesses to trigger and then it does a whole ten extra row refreshes that's still a negligible hit to performance.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: