Hacker News Reader

Comment by qubex | Hacker News Reader

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

View on HN

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

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.

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

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

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.

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/

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

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

Same patch I think.

You might mean this one:

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

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

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

You mean enable KPTI.

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.

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.

Reply on news.ycombinator.com