[airesQ]

Given Intel's dominance of the server market does this mean that datacenter computational capacity will see an overnight ~5% drop?

Is there enough spare capacity to cope with this? Will spot-instance prices go up? Will I need more instances of a given type to run the same workload?

[kevin_thibedeau]

Given what's been disclosed so far it seems an exploit using rowhammer techniques would be unlikely to work with ECC RAM. Consumer systems will be screwed unless a tolerable microcode update is released.

[kentonv]

I don't think this issue is related to rowhammer. I think people have been speculating about rowhammer because it's a famous hardware bug, but none of the details of page table isolation seem to align with a rowhammer-based attack.

[kevin_thibedeau]

This enables the first step in a rowhammer attack: identify the privileged address you want to target.

[kentonv]

Oh, are you thinking the KASLR bypass is actually the main problem, because it allows targeted rowhammer? I'm not sure if that's really true, since a KASLR bypass would give you a virtual address, and rowhammer would care more about physical addresses.

But in any case, the KASLR bypass is not the main vulnerability here. KASLR is widely seen as too leaky to be really useful. Linux would not rush out a >5% performance hit just to fix one of the many leaks.

[Shank]

I was under the impression that rowhammer could work because ECC ram can't correct for a high number of errors. Specifically "However, even such modules cannot correct multi-bit disturbance errors" from http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf.

[kevin_thibedeau]

With such a crude mechanism the odds are pretty slim that you can create all the right multi-bit flips in one go without hitting an intermediate state that triggers an ECC fault. Research theorizing and actual practice aren't always the same.

[spiznnx]

Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

[kuschku]

This patch is part of a patchset that isn’t merged yet. The patchset adds 29% (with PCID) or > 50% (without PCID) overhead to syscalls on Intel processors.

Overall, this has between 0.28% (best case application with barely any syscalls) and > 50% (du, which does lots of syscalls) impact on performance on Intel processors.

[amluto]

PTI has been merged.

[kuschku]

But it’s not been released yet, right?

[DSMan195276]

It's in the current release candidate, so on track to be in the next release in a few weeks.

[daenney]

> Nothing will happen since this patch will speed up AMD hardware, but leave Intel the same as before.

It doesn't speed up AMD hardware. Intel incurs a performance penalty (so it doesn't leave Intel the same as before), but that penalty doesn't make your AMD CPU magically go faster.