4 ms·

I thought that Rowhammer was a thing of the past. Out of curiosity I found code to test for this and ran it on some of my hosts. My old desktop - I7-4770K/DDR3

I thought that Rowhammer was a thing of the past. Out of curiosity I found code to test for this and ran it on some of my hosts. My old desktop - I7-4770K/DDR3 - was susceptible. My old server - Xeon X3460/DDR3+ECC - was not. I upgraded the desktop with components based on a Ryzen 7 7700X/DDR5. It tested not susceptible. I'm not sure if that's a result of RAM designed not to be susceptible or that (I think) DDR5 RAM uses modules with on die ECC. I was not able to test any of my Raspberry Pis because the test code used some facility available on the AMD64 architecture that is not available on the ARM64 processors. The newer Pi 4B and 5 use modules with on die ECC. It seems to me that ECC should prevent Rowhammer susceptibility. That should prevent it on server grade H/W for anything still in service and newer consumer systems. I have no idea if Rowhammer affects other architectures than AMD64.

trebligdivad 3y ago
Rowhammer is not architecture specific, since it's the DRAM rather than the CPU. The paper linked in the patch references other works showing every defence at rowhammer can be bypassed somehow (I've not followed them all) - e.g. it specifically says that ECC and the like can be bypassed.
- HankB99 3y ago
  Interesting. I did not expect that Rowhammer was architecture specific, only that the test I found was. I also did not expect that the various defenses, including ECC, could be bypassed.
  - adrian_b 3y ago
    It cannot be completely bypassed. The attacker cannot control precisely which bits will be erroneous. When much more than 2 bits become erroneous, in a small fraction of the cases no error will be detected but a wrong value will be read at the next access. However, in the majority of the cases an error will be detected, either non-correctable, or correctable in which case the corrected value will be wrong. Despite the fact that wrong corrections are possible, in a system with ECC that is configured correctly it should be impossible for a RowHammer attack to escape detection, unlike for a system without ECC memory. On a computer that is not defective, memory errors happen very seldom, typically one error after many months. Even only 2 correctable errors that happen in the same day represent an event that can be explained only by either a RowHammer attack or by a memory module that has become defective. Therefore, a well configured computer with ECC memory should alert immediately its administrator when 2 on more errors happen in the same day, even if they had been correctable errors, because this requires immediate action, either stopping a RowHammer attack or replacing the defective memory module. It would be pretty much impossible for any RowHammer attack to attain its target without triggering 2 or more ECC errors, which will reveal the attack attempt. Only when there is no ECC the attack can proceed undetected for a time long enough to be successful.
    - gnramires 3y ago
      Shouldn't an ECC non-correctable error trigger an immediate shutdown, because bad data could be committed to disk? (I guess unsafe shutdown could cause corruption elsewhere, but that seems like a reasonable risk) If attacks are a serious threat, then it would seem any alert that doesn't trigger immediate action would be risky (i.e. the attacker just erases alerts from logs).
thijsr 3y ago
RowHammer is not a thing of the past. In fact, modern DRAM chips are significantly more susceptible to RowHammer due to their increased chip density [1]. [1] https://arxiv.org/abs/2005.13121 https://arxiv.org/abs/2005.13121
- HankB99 3y ago
  Thanks for the link. I guess I thought wrong. But I have more questions. > with RowHammer protection mechanisms disabled I wonder what this means. Is it S/W mitigations or does it include H/W factors like disabling on-die ECC. It makes sense to me that with all other things being equal that higher density would lead to more susceptibility to Rowhammer. But as always, other things are not equal. I expect that on-die ECC would reduce susceptibility to Rowhammer and AFAIK that is used for DDR4 and DDR5 RAM, but perhaps not exclusively. Or did disabling "protection mechanisms" include disabling that (if it is even possible.)
  - sweetjuly 3y ago
    The mitigations are usually about limiting the number of times you can access without refreshing. ECC helps in detecting and correcting (obviously) but it doesn't solve the underlying issue that accessing a cell over and over can cause bit flips in neighbors. ECC can be defeated if uncorrectable errors are not fatal or if the attacker can just crash the system over and over. Being able to introduce memory errors is a fundamental and unmitigatable issue that must be resolved by making these errors impossible. This isn't a problem software can solve.
- omoikane 3y ago
  In the "countermeasures" section of the linked paper[1], it mentioned that there are some new techniques available, but repeatedly mentioned that they are not yet available in consumer systems. Maybe rowhammer will eventually be a thing of the past despite the increasing chip density. [1] https://arxiv.org/abs/2309.02545 https://arxiv.org/abs/2309.02545
tlb 3y ago
LPDDR4 and above are supposed to have a feature to detect too many accesses to the same few rows and initiate a refresh cycle. Implementation quality may vary.
- xgk 3y ago
  Have you ever seen any even moderately detailed specification of what the DRAM manufacturers do in this regard? I have not, and I looked. I am deeply sceptical .... I don't believe that Rowhammer mitigations happen inside the DRAM chips themselves, I think that they are being put into the memory controller that talks to DRAM. Since DRAMs with built-in Rowhammer defences would have to spend transistors on this defence, those transistors would be 'wasted' in situations where Rowhammer is not part of the attacker model.
  - tlb 3y ago
    It makes sense to put it in the DRAM controller for many reasons. One is that the DRAM silicon process is optimized for memory but terrible for logic. Also, a DRAM bank is several chips in parallel to get the data bus width, and they would all have to duplicate the logic. The disadvantage is that the controller and memory are made by different companies, so standards are required to agree on what access patterns are acceptable.
    - xgk 3y ago
      Agree. The extreme secrecy of DRAM manufacturers about the innards of their chips puts an additional obstacles in the way of memory controllers (MCs) implementing efficient Rowhammer defences. In particular, if the MC doesn't know which addresses are corresponding to neighbouring rows, how can an MC know with certainty that any concrete row is being attacked? (And, to the best of my knowledge, DRAM manufacturers don't give away this information.)
      - tlb 3y ago
        It might be good enough to detect a large number of accesses to any single row and then initiate a complete refresh. This wouldn't be triggered often by normal software. Most exploits have to use cache flush instructions, and with modern several-way-associative caches it would be rare for normal code to trigger it accidentally. In that case, the DRAM maker just has to specify the maximum number of accesses to any row.
dist-epoch 3y ago
Are you running the Ryzen DDR5 at stock speeds (4800 MT/s) or at some XMP profile.
- HankB99 3y ago
  Everything is at stock speed.

trebligdivad 3y ago

Rowhammer is not architecture specific, since it's the DRAM rather than the CPU. The paper linked in the patch references other works showing every defence at rowhammer can be bypassed somehow (I've not followed them all) - e.g. it specifically says that ECC and the like can be bypassed.

HankB99 3y ago
Interesting. I did not expect that Rowhammer was architecture specific, only that the test I found was. I also did not expect that the various defenses, including ECC, could be bypassed.
- adrian_b 3y ago
  It cannot be completely bypassed. The attacker cannot control precisely which bits will be erroneous. When much more than 2 bits become erroneous, in a small fraction of the cases no error will be detected but a wrong value will be read at the next access. However, in the majority of the cases an error will be detected, either non-correctable, or correctable in which case the corrected value will be wrong. Despite the fact that wrong corrections are possible, in a system with ECC that is configured correctly it should be impossible for a RowHammer attack to escape detection, unlike for a system without ECC memory. On a computer that is not defective, memory errors happen very seldom, typically one error after many months. Even only 2 correctable errors that happen in the same day represent an event that can be explained only by either a RowHammer attack or by a memory module that has become defective. Therefore, a well configured computer with ECC memory should alert immediately its administrator when 2 on more errors happen in the same day, even if they had been correctable errors, because this requires immediate action, either stopping a RowHammer attack or replacing the defective memory module. It would be pretty much impossible for any RowHammer attack to attain its target without triggering 2 or more ECC errors, which will reveal the attack attempt. Only when there is no ECC the attack can proceed undetected for a time long enough to be successful.
  - gnramires 3y ago
    Shouldn't an ECC non-correctable error trigger an immediate shutdown, because bad data could be committed to disk? (I guess unsafe shutdown could cause corruption elsewhere, but that seems like a reasonable risk) If attacks are a serious threat, then it would seem any alert that doesn't trigger immediate action would be risky (i.e. the attacker just erases alerts from logs).

thijsr 3y ago

RowHammer is not a thing of the past. In fact, modern DRAM chips are significantly more susceptible to RowHammer due to their increased chip density [1]. [1] https://arxiv.org/abs/2005.13121 https://arxiv.org/abs/2005.13121

HankB99 3y ago
Thanks for the link. I guess I thought wrong. But I have more questions. > with RowHammer protection mechanisms disabled I wonder what this means. Is it S/W mitigations or does it include H/W factors like disabling on-die ECC. It makes sense to me that with all other things being equal that higher density would lead to more susceptibility to Rowhammer. But as always, other things are not equal. I expect that on-die ECC would reduce susceptibility to Rowhammer and AFAIK that is used for DDR4 and DDR5 RAM, but perhaps not exclusively. Or did disabling "protection mechanisms" include disabling that (if it is even possible.)
- sweetjuly 3y ago
  The mitigations are usually about limiting the number of times you can access without refreshing. ECC helps in detecting and correcting (obviously) but it doesn't solve the underlying issue that accessing a cell over and over can cause bit flips in neighbors. ECC can be defeated if uncorrectable errors are not fatal or if the attacker can just crash the system over and over. Being able to introduce memory errors is a fundamental and unmitigatable issue that must be resolved by making these errors impossible. This isn't a problem software can solve.
omoikane 3y ago
In the "countermeasures" section of the linked paper[1], it mentioned that there are some new techniques available, but repeatedly mentioned that they are not yet available in consumer systems. Maybe rowhammer will eventually be a thing of the past despite the increasing chip density. [1] https://arxiv.org/abs/2309.02545 https://arxiv.org/abs/2309.02545

tlb 3y ago

LPDDR4 and above are supposed to have a feature to detect too many accesses to the same few rows and initiate a refresh cycle. Implementation quality may vary.

xgk 3y ago
Have you ever seen any even moderately detailed specification of what the DRAM manufacturers do in this regard? I have not, and I looked. I am deeply sceptical .... I don't believe that Rowhammer mitigations happen inside the DRAM chips themselves, I think that they are being put into the memory controller that talks to DRAM. Since DRAMs with built-in Rowhammer defences would have to spend transistors on this defence, those transistors would be 'wasted' in situations where Rowhammer is not part of the attacker model.
- tlb 3y ago
  It makes sense to put it in the DRAM controller for many reasons. One is that the DRAM silicon process is optimized for memory but terrible for logic. Also, a DRAM bank is several chips in parallel to get the data bus width, and they would all have to duplicate the logic. The disadvantage is that the controller and memory are made by different companies, so standards are required to agree on what access patterns are acceptable.
  - xgk 3y ago
    Agree. The extreme secrecy of DRAM manufacturers about the innards of their chips puts an additional obstacles in the way of memory controllers (MCs) implementing efficient Rowhammer defences. In particular, if the MC doesn't know which addresses are corresponding to neighbouring rows, how can an MC know with certainty that any concrete row is being attacked? (And, to the best of my knowledge, DRAM manufacturers don't give away this information.)
    - tlb 3y ago
      It might be good enough to detect a large number of accesses to any single row and then initiate a complete refresh. This wouldn't be triggered often by normal software. Most exploits have to use cache flush instructions, and with modern several-way-associative caches it would be rare for normal code to trigger it accidentally. In that case, the DRAM maker just has to specify the maximum number of accesses to any row.

dist-epoch 3y ago

Are you running the Ryzen DDR5 at stock speeds (4800 MT/s) or at some XMP profile.

HankB99 3y ago
Everything is at stock speed.