Half-Double: New hammering technique for DRAM Rowhammer bug
security.googleblog.com
security.googleblog.com
>> 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
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.
https://course.ece.cmu.edu/~ece740/f13/lib/exe/fetch.php?med...
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.
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.
Reference: https://www.google.com/amp/s/cloudblog.withgoogle.com/produc...
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.
But dropping the analogies entirely and stating explicitly is a lot better. ECC makes rowhammer less likely to succeed and slower to exploit.
They are the authors behind trrespass and smash. In their classes, when I followed them, we went into their research extensively.
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.
Oh, hello web browsers!
https://github.com/google/hammer-kit/blob/main/20210525_half...
Choose two.
And the lack of hardware sharing is more for lack of demand than lack of ability.
The S in IoT stands for security.
> 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?
https://en.wikipedia.org/wiki/DRAM
https://en.wikipedia.org/wiki/Row_hammer
https://en.wikipedia.org/wiki/Soft_error
https://en.wikipedia.org/wiki/Crosstalk
> [...] 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