Linux KVM Virtualization Had Mistakenly Been Applying L1TF Workaround To Unaffected CPUs

[phoronix]

Phoronix: Linux KVM Virtualization Had Mistakenly Been Applying L1TF Workaround To Unaffected CPUs

The all-important Linux Kernel-based Virtual Machine (KVM) code for open-source virtualization had mistakenly been applying its L1TF workaround for unaffected CPUs -- namely AMD EPYC CPUs -- for the past several months until the issue was uncovered this week...

http://www.phoronix.com/scan.php?page=news_item&px=KVM-L1TF-Whoops

[ddriver]

Lemme guess, the source code responsible was generously contributed by the intel corporation?

[skeevy420]

Lemme guess, the source code responsible was generously contributed by the intel corporation?

If you'd have RTFA....AMD did the contribution and fucked themselves. Red Hat unfucked them.

[dlq84]

Lemme guess, the source code responsible was generously contributed by the intel corporation?

Try reading the article next time.

[ddriver]

If you'd have RTFA....AMD did the contribution and fucked themselves. Red Hat unfucked them.

IIRC that very explicit clarification was not part of the initial article, must have been added in light of my comment. At any rate, I cannot help but feel curious how exactly memory encryption related code ended up triggering a redundant security issue mitigation. That meticulous "intel didn't do it" is not suspicious in the least...

Also F much? That's bad karma right there

[Michael]

IIRC that very explicit clarification was not part of the initial article, must have been added in light of my comment. At any rate, I cannot help but feel curious how exactly memory encryption related code ended up triggering a redundant security issue mitigation. That meticulous "intel didn't do it" is not suspicious in the least...

It was part of the original article. When writing the article I was curious myself if it was attributed to Intel's original L1TF workarounds or not, etc and knew otherwise people would be trying to jump on Intel right away if so.

[Azrael5]

Who knows how many useless workarounds are applied to the Cpu which are not affected by bugs so to make their performance worst. Idiocy has no limit.

[gukin]

Paolo Bonzini, what a great name and he's going to make guests on EPYC even faster. This is why we pay Redhat to do what they do.

[ddriver]

It was part of the original article. When writing the article I was curious myself if it was attributed to Intel's original L1TF workarounds or not, etc and knew otherwise people would be trying to jump on Intel right away if so.

Yes, this is correct, as confirmed by a screenshot I took of the article. My bad. Yet credit must be given where it is due, intel's "default vilianist" position is not exactly unwarranted. What times we live in, intel - innocent.

At the same time, intel seems to be overly strict and meticulous when reviewing and delaying amd code contributions. Curious how they missed this one.

Also curious that such an erroneous flag calculation would not result in anything catastrophic and immediately obvious, in a pure stroke of luck, merely silently applying a performance decreasing mitigation.

Lastly, I am curious as to how exactly did you conclude that it was "a simple mistake made by an AMD engineer", did you investigate the matter into detail?

> To fix this, avoid splitting gfns as long as the processor does not have the L1TF bug

It seems to me that if the issue indeed arose from "a simple mistake made by an AMD engineer", the solution would involve fixing that mistake.

The gfns split was part of the security issue mitigation, even tho that wasn't necessary in the case of amd CPUs to begin with.
It conflicted with how amd implements memory encryption via the leftover bits that are unused for physical addressing.
Which led to wrong flag evaluation in turn triggering the mitigation on amd CPUs.

So what led to executing the mitigation code in the first place? I sure do hope it wasn't them funky bits that got corrupted by running the unneeded mitigation...

This hints at redhat architects not doing their share of tech docs reading. If you do dirty stuff like using physical addressing leftover bits, you do have to be meticulous at how different architectures handle those. And full memory encryption, being a recent novelty, and a fairly important one in this day and age of poor security, should have gotten more attention.

But still, that issue wouldn't have manifested in the first place had not execution taken an unnecessary mitigation code path.

[cynic]

Paolo Bonzini, what a great name and he's going to make guests on EPYC even faster. This is why we pay Redhat to do what they do.

what's wrong with his name?