The Great Beast is armored!

All my readers should be aware of the Rowhammer attack by now.

It gives me great pleasure to report that thanks to our foresight in specifying ECC memory for the design, the Great Beast of Malvern has armor of proof against this attack. The proof being over a thousand runs of the Rowhammer test.

Thank you, everyone who threw money into the Beast’s build budget. If y’all hadn’t been so generous, the build team might have had to make compromises. One of the most likely items to be cut would have been ECC…because registered ECC DRAM at the Beast’s speeds is so freaking expensive that the memory was about a third of the entire build budget. And now we’d have a vulnerable machine.

As it is, the Beast roars in triumph over the Rowhammer.

Oh, and what I’m currently doing with the Beast? Why, I’m repairing the very fabric of time..itself! Explanation to follow, probably early next week.

17 thoughts on “The Great Beast is armored!

  1. Reading a description of how this bug works I can’t help but wonder how long it will be until all RAM has to be ECC in order to function properly.

  2. It used to be the case – going back to the earliest 8-bit hobbyist systems – that the most expensive part of a decent computer was the memory. Are we back to that state now? – assuming, of course, that we ever left it.

  3. “Why, I’m repairing the very fabric of time..itself! Explanation to follow, probably early next week.”

    Don’t you mean early *last* week? :-)

  4. > Reading a description of how this bug works I can’t help but wonder how long it will be until all RAM has to be ECC in order to function properly.

    It’s either that, or more frequent DRAM refreshes (implying lower performance) – a pretty clear tradeoff. The cleanest solution, AIUI, would be to have smarts in the controller so that it can prioritize refreshing rows near those that are frequently accessed.

    A pretty big priority right now is developing a rowhammer test as part of memtest86+ (note the “+”, as plain vanilla memtest86 is closed-source, commercial SW), so that folks can actually tell which modules are problematic.

  5. Hm. Macs are usually equipped with ECC memory, at least the desktops (haven’t bought a laptop in a while). Seems like an inspired design decision on their part.

  6. Interesting. Late 2013 Powerbook Retina (Work lapdog) currently at 450 iterations with no problems.

  7. HP has a solution to this in the future: memristors everywhere. For now, ECC is a good stopgap for something the DRAM manufacturers may have to look into new designs to fix.

  8. > The cleanest solution, AIUI, would be to have smarts in the controller so that it can prioritize refreshing rows near those that are frequently accessed.

    And rows that relate to privileged functions like a page table. A user process crashing itself due to bad memory access patterns (is it possible to trip this innocently?) is less of an issue than privilege escalation.

  9. > Macs are usually equipped with ECC memory

    No, they are not. The only Apple computer that has ECC Memory is the Mac Pro. None of their other computers had ECC.

  10. @Jorge Dujan: I don’t think he’ll get the reference. Though I’d be pleasantly surprised to be wrong.

    Given what’s been posted on this blog before, I’m going to guess he’s been busy with some heavy wizardry somewhere deep within the innards of gpsd. Or, given recent news, perhaps something involving NTP.

    Maybe both.

  11. That…was a goooooood guess.

    Hmmm…given your previous links to time service and gpsd docs, I thought it was a fairly obvious inference.

    Looking forward to that post :)

Leave a Reply

Your email address will not be published. Required fields are marked *