>> 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.
> 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.
ECC doesn't prevent rowhammer, but it makes it a lot easier to spot.
If you flip only one bit, that will at least increase a correctable error count. It you flip only two bits, most OSes will panic, although sophisticated OSes can kill only the process which had that address mapped, or take that address out of the mapping and kill the process on access, etc. It's only if you flip three bits that it might be undetected.
From what I've seen the probability of flipping one or two bits is much higher than three or more, so ECC is useful to probabalistically turn a security bypass into a denial of service.
GCP at least takes the approach of monitoring single and double bit flips to kill offending VMs.
There's also a potential performance tradeoff (no idea if GCP is using this) of running some single channel DIMMs for isolating VMs from the kernel and kvm userspace.
ECC fails to prevent rowhammer in more or less exactly the same way that address space randomization and similar hardening techniques fail to prevent stack smash attacks.
Which is to say, it basically prevents rowhammer in a practical sense. You can flip the bits, but you don't have the level of control needed to flip the right bits.
I'm not sure this actually makes them wrong, if you take their statement as "ECC makes the attack more difficult/ statistically less likely". The attack you're describing is sort of akin to a heap spray attack to improve your chances of hitting your shell code.
But dropping the analogies entirely and stating explicitly is a lot better. ECC makes rowhammer less likely to succeed and slower to exploit.
The more I learn about security the less I can understand anyone trusting the security of hardware that is not in a secure location they own.
Yes rowhammer is an issue, but if you know you're a target then you have no business computing somewhere that has untrusted individuals accessing the hardware.
Depends on how you define performance; a decent chunk of IoT devices have good performance on a per-joule basis (rather than per-second), although that's nowhere near guarranteed.
And the lack of hardware sharing is more for lack of demand than lack of ability.
I basically agree, but the word "shared" needs a bit more refinement; outright system partitioning --- this VM gets CPUs 1-2 and a chunk of DRAM, that VM gets CPU 3-4 and a disjoint chunk of DRAM --- seems safer than the kind of fine-grained oversubscribed resource sharing that's common today.
> Sometimes bits just flip due to "cosmic rays"; or, logically, also due to e.g. neutron beams and magnetic fields.
> With rowhammer, there are read/write (?) access patterns which cause predictable-enough information "leakage" to be useful for data exfiltration and privilege escalation.
> With the objective of modeling qubit interactions using quantum-mechanical properties of fields of electrons in e.g. DRAM, Is there a way to use DRAM electron "soft errors" to model quantum interactions; to build a quantum computer from what we currently see as errors in DRAM?
> If not with current DRAM, could one apply a magnetic field to DRAM in order to exploit quantum properties of electrons moving in a magnetic field?
> [...] are there DRAM read/write patterns which cause errors due to interference which approximate quantum logic gates? Probably not, but maybe; especially with an applied magnetic field (which then isn't the DRAM sitting on our desks, it's then DRAM + a constant or variable field).
> I suppose to test this longshot theory, one would need to fuzz low-level RAM loads and search for outputs that look like quantum gate outputs. Or, monitor normal workloads which result in RAM faults which approximate quantum logic gate outputs and train a network to recognize the features.
> I am reminded of a recent approach to in-RAM computing that's not memristors.
> Soft errors caused by cosmic rays are obviously more frequent at higher altitudes (and outside of the Van Allen radiation belt).
Thought I'd ask this here as well.
Quantum tunneling was the perceived barrier at like DDR5 and higher densities FWIU? Barring new non-electron-based tech, how can we prevent adjacent electrons from just flipping at that gate grid gap size?
Other Quantum-on-Silicon approaches have coherence issues, too
>> 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