Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena(arxiv.org)
43 pointsby Jimmc4147 hours ago1 comment
  • mikewarot6 hours ago
    It's my long standing opinion[1] that we shouldn't accept any RAM that can be subject to random bit flips. Most of the mitigations are just security through obscurity.

    [1] https://news.ycombinator.com/item?id=33860477

    • inigyou6 hours ago
      My computer with a lot of ECC DDR5 sometimes catches several bitflips in a day. I know this because they are reported to dmesg and sometimes I look at dmesg.

      Intel decided long ago that you would need to pay more to not be subject to random bitflips. So it's an AMD system.

    • e2le6 hours ago
      I was shocked to learn that around 10% of Firefox crashes are caused by bit flips.

      https://news.ycombinator.com/item?id=47252971

      • inigyou6 hours ago
        Most software is like this. Factorio had a weird one where some routers dropped UDP packets with zero checksum.
    • Retr0id6 hours ago
      Intel MEE addressed this (https://eprint.iacr.org/2016/204.pdf), by treating DRAM as entirely untrusted (assuming an attacker with arbitrary physical read/write capabilities), but then they discontinued it.

      Regarding your linked comment:

      > If we had properly tested and validated RAM, RowHammer wouldn't work, ever.

      While it's exacerbated by physical defects and tight timings, it's really a fundamental problem with how DRAM works. It's frankly a miracle it works in the first place.

      • inigyou6 hours ago
        No. If it was designed really well, it would trigger extra refreshes as needed. It would know how much accessing a row disturbs nearby rows and how much disturbance a row can suffer before it needs a refresh to prevent data corruption. It would know how long a row can be held open for, too. There is no fundamental theorem that rowhammer must work. It was an engineering tradeoff.

        I don't think we can blame DRAM designers for flying a teensy bit too close to the sun here, since this is no problem in normal operation and only appears under adversarial scenarios. We can blame them for not fixing it once it was discovered. And we can definitely blame Intel for making ECC RAM a market segmentation feature.

        • Retr0id6 hours ago
          What you describe is the Target Row Refresh (TRR) mitigation, and it can be bypassed via "half-double" attack.
          • inigyou5 hours ago
            Where did I imply that they should use an incorrect underestimation of row disturbance? If they actually measured these things, they'd know how far away a disturbance can be created before it becomes so weak the normal refresh cycle fixes it.
            • Retr0id5 hours ago
              It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.
              • gpm4 hours ago
                It doesn't need to be fully accurate, merely always conservative. It's a question of cost (how much performance does the conservative estimate waste) not feasibility.
              • inigyou5 hours ago
                Okay then refresh the whole thing and not just a single row whenever TRR is triggered.

                Or refresh the whole thing after a certain number of row activations.

                Or interleave activations with refreshes. Say, after every 5 activations, refresh the next row in the refresh cycle.

                I'm not a DRAM expert. They can figure it out. I promise if you refresh the whole chip after every row activation you won't have rowhammer. It'll be too slow though. Somewhere in between is the fastest point where there isn't rowhammer.

                • 5 hours ago
                  undefined
              • bell-cot5 hours ago
                It doesn't need to be a fully accurate simulation, any more than your car needs a fully accurate ICE simulation to decide "Change the engine oil".

                Just count accesses to each row, and refresh the adjacent row(s) when some limit is reached.

                • inigyou4 hours ago
                  Half-Double is an attack where you hammer the rows 2 spaces away so that the automatic refresh on the rows 1 space away is what actually hammers the target row.
                  • bell-cot3 hours ago
                    Yes? When a given row's counter hits the limit, you refresh every other row which your actually-competent testing has shown might maybe possibly be compromised by that activity.

                    Same as a good car's computer doesn't make a bunch of rosy assumptions about whether the oil needs changing or not - the automotive engineers actually do their jobs, test the crap out of their engine designs, and base the oil-change criteria on the real-world test results.

                    (JIC: "Adjacent" has a range of meanings in English. Those go from "the singular closest neighbor, within further constraints on type, orientation, etc." to "relatively close to by some metric". But I am not an EE, let alone a chip architect, to know the "real insider" lingo here.)

      • anon_rh_guy4 hours ago
        Little known fun fact: the MEE's checksum updates... were one of the most successful Rowhammer patterns... :-p
        • Retr0id3 hours ago
          Interesting - but presumably used to attack rows outside of SGX?