5 ms·

Takes longer though.

• bell-cot 4y ago
  IIR - So long as the time it takes is longer than the periodic DRAM refresh interval, the ECC can effectively stop rowhammer.
  • j16sdiz 4y ago
    https://ieeexplore.ieee.org/document/8835222 https://ieeexplore.ieee.org/document/8835222 > . In addition, we show that, despite the non-trivial constraints imposed by ECC, ECCploit can still be powerful in practice and mimic the behavior of prior Rowhammer exploits
    • sroussey 4y ago
      Just like with non-ecc dram, quality levels vary per dimm, and you can avoid this with good quality ecc dram.
    • toast0 4y ago
      I didn't read the full paper, which is very interesting, but on systems with proper ECC configuration[1], the scanning portion of the process would generate a huge number of machine check exceptions. Having run a large number of ECC enabled machines, high volume ECC correctable errors are disruptive to normal processing, and the machine goes out of service for repair quickly. If I were running a multi-tenant cloud, knowing that RowHammer is a thing, I would migrate the VMs on a machine throwing correctable errors, and also track the customers. VM migration during scanning is going to result in inconsistent data, and successful exploitation seems unlikely. Tracking the customers, allows one to prevent repeat rowhammerers from accessing your systems. That said, it's still very interesting and many systems have improper ECC configuration. ECC without reporting isn't going to mitigate RowHammer; nor will it help to have ECC with reporting, if the reporting is ignored, etc. [1] I didn't make it to their system configurations, but I did see their description that only one system under test properly responded to errors, by logging errors, and crashing on uncorrectable errors.