[rpns]

It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on.

> 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.

[qubex]

“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?

Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.

[gnicholas]

> What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?

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.

[qubex]

That's probably a more accurate interpretation, but the wording is maddeningly ambiguous... just the fact that we can sit here and posit such wildly divergent interpretations is testament to how utterly woolly the statement itself is.

[mywittyname]

> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.

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.

[betterunix2]

https://lkml.org/lkml/2017/12/27/2

It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).

[mywittyname]

I was making reference to this [1].

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...

[betterunix2]

Same patch I think.

[cesarb]

That patch would be this git commit: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...

Not yet on the mainline AFAIK, but I'd guess that whole branch will be merged soon (before the next release candidate).

[qubex]

I don't know if it's possible to see who contributed that patch (yet), but I’m cynical enough to half-expect that the “assume all x86 processors are insecure” patch might come from an Intel engineer...

[mywittyname]

I would not be surprised at all, considering the patch I saw for the AMD processors was literally a one-line if statement around the set cpu insecure flag that added a check for AMD processors.

Google is failing me or I'd post a link.

[omeid2]

the patch was by Thomas Gleixner[0], who is not an Intel Engineer.

AMD has since pushed a patch to "not enable PTI on AMD processors" [1]

[0] https://patchwork.kernel.org/patch/10138833/

[1] https://patchwork.kernel.org/patch/10142563/

[GalacticDomin8r]

You might mean this one:

https://lkml.org/lkml/2017/12//27/2

[mywittyname]

Yeah.

I just found it in their git repo, looks like it was added today. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...

[angelsl]

You mean enable KPTI.

[pas]

Process Context ID for TLB entries to make the flipping efficient - if results in constant time failures, will solve the perf issue.

PCID is in Intels since Westmere.

[tytso]

The 5% to 30% performance hit (dependent on workload) was measured with PCID. The hit may be more on older CPU's that do not support PCID.

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.

[tgarma1234]

Because let's be honest: when I bought my XEON and i5 processors, performance wasn't the issue that made me pick Intel over AMD. PUH-LEASE. This is the worst kind of customer service malarky I have read in a while.

We are not average computer users.

[bartread]

> 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.

[IMcD23]

According to Google's Project Zero post [1], Intel has known about this since 2017-06-01.

1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...

[Havoc]

>Presumably the statement was hastily put together

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.

[bo1024]

But the story seems to only have broken to "mainstream" yesterday and has gained a lot of attention in the last 24 hours.

[Havoc]

Sure. Catching mainstream media off guard is different from Intel though. There is no way this caught them by 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)

[betterunix2]

They may not have realized it would make it to the media; until this week there was not much chatter, and then today Intel's stock is trading lower while every other chipmaker is trading higher. Their PR team may not have been prepared for that situation, and they may be worrying about CTOs giving more serious thought to AMD (or even non-x86 chips) for their data center upgrades.

[ovao]

> A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.

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.

[malchow]

It's odd that they named AMD and ARM, but did not name Apple and Microsoft, isn't it?

[teilo]

Why? It's not an OS bug. It's a hardware bug.