FPGA developer here.

In a former project (with a custom board and FPGA, no processor), we encountered random bugs. We put many checks and finally came to the conclusion that our DDR modules were flipping bits randomly, but only on normal load. All test benches were running fine. Putting the modules in a PC did not show any problem.

How can you tell your boss "all DDR modules are faulty but run fine in a PC" and not seem crazy?

It was when I read about rowhammer attacks that I made the link. Changing the addressing schema completely solved the issue.

All these hardware related failures/attacks may not be a threat (yet), but for me, the underlying sand castle we are building things on is very worrying.

>Changing the addressing schema completely solved the issue.

Can you elaborate at all? Do you mean you changing the FPGA to not write to exactly the same spots over and over? And just set up something up similar to wear leveling?

It was very simple, I kept all the "logical" addresses the same, but swapped some low address bits with high address bits at the memory controller interface.

With this, the slowly moving indexes became big jumps. This avoids reading the same row over and over again (mixed with other requests).

> This avoids reading the same row over and over again

Didn't you notice a huge drop in performance producing row-buffer conflicts over and over ?

Good question. Jumping around the memory is clearly not good for throughput. Before the change, the mixing of requests between processes was already detrimental for performance anyway. All I can say is that we needed a fixed bandwidth and it was enough, before or after the change.

Sure you didn't just have a timing problem, such as the all-too-common "Hmm, that wasn't a false path after all" variety?

When I read about rowhammer, I did analyse carefully the memory request pattern and found many similarities to a rowhammer attack on PC. It was several processes issuing small requests on alternating rows, with slowly moving indexes.

After I implemented the change and had a stable system, I went as far as implementing a switch of addressing pattern so that, all other things being equal, I could trigger the bug or not. And it worked as expected.

So yes, i am very confident in the analysis.

There was a practical attack to gain root on android via it wasn’t there?

https://arstechnica.com/information-technology/2018/07/new-r...

There was at least a TA dumper for Sony Xperia models based on Dirtycow that allegedly worked for earlier Android N builds...

You mean the attack that required you to have malware already on your phone (RAMpage)? Or the one that was mitigated via Chrome years back (Drammer)?

Cause both are impractical. Using a minutes-long RAMpage attack to root an already compromised device is impractical. There are easier ways to do that. And it's easier to update Chrome than the Android OS, for Drammer, so that's been mitigated ages ago. Nobody uses a three-year-old Chrome on Android. Get real ... and spare me the comment about how some users don't update apps, cause they do, Google makes sure to spam users about it daily.

To be fair, it's as easy to turn off the daily notices as it is to turn off the automatic updates. And, as updates seem to break various things at least as often as they improve things it's nothing unusual about users turning off one or both of the features.

(Note that I'm not commenting on the attack vector at all, only about the Android update settings)

It's not just easy but I have some friends who dom't update their (low end) phones because they're afraid that the updates will slow the system down.

If you have read the article you would have known that Dan took a very measured approach and didn't over-hype anything. The headline might have led you into reaching your conclusion, and I don't blame you.