Hacker News Reader

Comment by ben_w | Hacker News Reader

This is probably a native question, but: could this sort of attack be prevented by having the physical values be trivially encrypted version of the logical values? I’m thinking something as simple as:

    $value XOR f(memory address, random number etched onto chip)

View on HN

That could certainly make it more difficult to exploit, sure, but keep in mind that being able to force a specific value change is not a hard requirement for this to be a security bug.

Even then, memory vendors tend to want to compete on frequency and access timings, which means doing any additional work not strictly required by the JEDEC standard will make their product appear worse than competing products, so I doubt they will want to do that.

Plus a similar technique could actually be done by the CPU's memory controller to similar effect, and historically DRAM design has favored pushing things to the controller when possible.

Flipping a bit flips the output of xor.

AMD EPYC processors already support AES encryption of memory (https://developer.amd.com/sev/) where VMs themselves cannot know the key. Interesting that I didn't see that mentioned in the paper as a possible mitigation.

Why do you believe this would help? Have you seen the attack from the BlackHat?[1] It doesn't require being able to read any plain text and it doesn't matter how the data is stored, only that it's near. You don't even have to have any access to the target memory or even know where it is, only the ability to cause something else to read it predictably.

1. https://www.blackhat.com/docs/us-15/materials/us-15-Seaborn-...

Reply on news.ycombinator.com