[HN Gopher] Half-Double: New hammering technique for DRAM Rowham...
___________________________________________________________________
Half-Double: New hammering technique for DRAM Rowhammer bug
Author : fqazi
Score : 118 points
Date : 2021-05-25 16:02 UTC (6 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| zerof1l wrote:
| In case someone is wondering, ECC DRAM does not prevent rowhammer
| attack.
| toast0 wrote:
| 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.
| benlivengood wrote:
| 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.
|
| Reference: https://www.google.com/amp/s/cloudblog.withgoogle.
| com/produc...
| ajross wrote:
| 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.
| pedro2 wrote:
| wrong. https://www.vusec.net/projects/eccploit/
| Dylan16807 wrote:
| That will work some of the time, but it requires the system
| to ignore a lot of single bit errors and keep running.
| staticassertion wrote:
| 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.
| ljhsiung wrote:
| 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
| nautilus12 wrote:
| Why is does the image at the top of the blog post for half double
| that it links to have something that looks like a crochet needle?
| [deleted]
| patte wrote:
| > We call this attack "Half-Double" inspired by the crochet
| stitch that is taller than a single crochet but shorter than a
| double.
|
| https://github.com/google/hammer-kit/blob/main/20210525_half...
| RcouF1uZ4gsC wrote:
| Security, Performance, Shared Hardware
|
| Choose two.
| meepmorp wrote:
| Depending on your first pick, two might be pushing it.
| topspin wrote:
| Pick up to two. Zero is valid; as in IoT.
| a1369209993 wrote:
| 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.
|
| The S in IoT stands for security.
| quotemstr wrote:
| 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.
| jacksnipe wrote:
| Not if those CPUs share one cache!
| jeffbee wrote:
| On Xeon at least you can statically allocate last-level
| cache space, and the L1 and L2 caches are dedicated to
| cores already.
| Taek wrote:
| Does running untrusted JavaScript count as shared hardware?
___________________________________________________________________
(page generated 2021-05-25 23:00 UTC)