Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable.
Not saying this is the right interpretation, just another possibility.
The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD.
There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD processors, but I'm not sure if it made it into the mainline.
It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).
The original fix had a comment that literally said, "/* Assume for now that ALL x86 CPUs are insecure */" They've since added a check to exclude AMD processors.
[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
Not yet on the mainline AFAIK, but I'd guess that whole branch will be merged soon (before the next release candidate).
Google is failing me or I'd post a link.
AMD has since pushed a patch to "not enable PTI on AMD processors" [1]
I just found it in their git repo, looks like it was added today. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
PCID is in Intels since Westmere.
So Intel might make out OK on this, since people will have to update their servers, and right now there are many more x86 server hardware choices which use Intel chips. The truly scary thing from Intel's perspective is if people decide to use this as an opportunity to move to AMD, or worse for them, completely outside the x86 ecosystem, to ARM64 or PPC64LE systems. I have heard accusations that Intel has strong-armed motherboard manufacturers so there are't that many choices for those other platforms --- at least so far. But of course, everything can change over time.
We are not average computer users.
Exactly.
The "average" computer user may not notice the difference, but servers running Intel processors are used by businesses, hospitals, government, the military, cloud providers, and on and on. Often these organisations are thrashing this infrastructure to within an inch of its life.
Until fairly recently I was consulting and, no exaggeration, one of my former clients: if their SQL Server host takes a 15%, never mind a 30%, performance hit, they're screwed.
I personally have just been the prime mover in the procurement of a server costing £25k with a 3 year support contract, pretty carefully specced according to performance. And you're telling me I should be OK with that machine taking a 30% performance hit below what we specced? No way.
EDIT: Sorry, original version of last sentence was a bit out of order - the tone of that release got under my skin a bit.
1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...
I don't think so. Given that both *nix and MS seems to have been working on this for at least a month already it can't have come as a surprise.
If anything it reads like it was very carefully crafted by lawyers to make sure they don't get sued to hell for a defective product. (It's not but lawyers are gonna lawyer)
Particularly bizarre considering the use of "believes". If Intel disbelieved that their own products are the best in any particular respect, that might actually warrant a press release on its own.
> Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.
> Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
It's interesting to note what it doesn't say – as it would seem to imply that for some workloads the performance impact will be significant.