LLVM Lands Performance-Hitting Mitigation For Intel LVI Vulnerability

[Michael]

I suppose if programs are compiled with these mitigations, they will run slow on all processors, regardless if they are known to be vulnerable or not ?

Right there is no per-CPU ID handling.

[mppix]

Right there is no per-CPU ID handling.

.. so a fully mitigated kernel would be slow also on AMD?

[Raka555]

.. so a fully mitigated kernel would be slow also on AMD?

Correct.
But these are compiler mitigations. They are separate from other mitigations that you can enable/disable in the kernel.
If you compile the kernel with a compiler which is doing full mitigation, then the resulting kernel will also be slower, regardless whether it is an AMD or Intel CPU and regardless which options you enabled in the kernel.

This mitigation is adding indirect thunk support that replaces each indirect call/jump with a direct call to a thunk that has a load fence (LFENCE) and then JMPQ.

So indirect call/jump will be replaced, regardless of Intel/AMD.

[Raka555]

Right there is no per-CPU ID handling.

All of a sudden Distro's like Gentoo is looking a lot more appealing.
They compile everything for YOUR CPU when you install and performance of "generic" Distro's were good enough not to bother with the extra hassle.
I avoided Gentoo as it was too time consuming.

Is Gentoo the only major-ish one that works like this ? (I know about Sabotage linux as well, but that is a tiny, mostly experimental distro)

[duby229]

Correct.

I'm not so certain about that. The way AMD's front-end hardware issues micro-ops is different and seems unaffected by these types of mitigations to me. At least in the case of Meltdown type vulnerabilities the mitigations have no affect on AMD hardware. Zen doesn't allow the type of overflows that meltdown exploits so preventing such overflows, which zen doesn't allow anyway, has no affect. It might waste a few cycles executing code that has no affect, but you're looking at a few cycles at worst.

[duby229]

All of a sudden Distro's like Gentoo is looking a lot more appealing.
They compile everything for YOUR CPU when you install.
I avoided Gentoo as it was too time consuming.

Is Gentoo the only major-ish one that works like this ? (I know about Sabotage linux as well, but that is a tiny, mostly experimental distro)

Sabotage isn't really on par with Gentoo. I hate to say it, but the next best thing is FreeBSD, but then Linux is miles ahead of BSD in desktop usage scenarios, so not really.

[Raka555]

I'm not so certain about that. The way AMD's front-end hardware issues micro-ops is different and seems unaffected by these types of mitigations to me. At least in the case of Meltdown type vulnerabilities the mitigations have no affect on AMD hardware. Zen doesn't allow the type of overflows that meltdown exploits so preventing such overflows, which zen doesn't allow anyway, has no affect. It might waste a few cycles executing code that has no affect, but you're looking at a few cycles at worst.

I edited my answer above to elaborate a bit more. I will copy it here as well.

But these are compiler mitigations. They are separate from other mitigations that you can enable/disable in the kernel.
If you compile the kernel with a compiler which is doing full mitigation, then the resulting kernel will also be slower, regardless whether it is an AMD or Intel CPU and regardless which options you enabled in the kernel.

[markg85]

markg85 Securing your OS makes no sense to you? It should be advertised everywhere, so people will buy AMD CPU next time. Intel should be sued for such performance loses.

in this case with extremes of 90% performance loss. The average case seems more closely to 10-20%. That's not worth it for consumer and programmer aimed distributions. Or anything non server related. So distributions like Fedora, Arch, Ubuntu, Suse, Clear, .. should not apply this.

Mind you, even Intel says that this leak is very difficult to abuse.

But you're free to have a mindset like "oh, security issue, i'll take any patch"... enjoy your slowdowns then.

Welcome to Security Research in 2020. You can endlessly debate the ethics of hyping research findings, but that ship has sailed. No one is going to listen to you. The problem is many vendors will ignore security problems unless they're widely reported and hyped up. Bad press for damaging security incidents means lost revenue. Secondly, this is as much about building visibility and reputations as it is reporting solid research. Visibility and reputation brings in funding. People don't eat without funding. If you don't like that, well. no one is forcing you to follow along, but don't complain if you passed up $10k from a bug bounty by being the "responsible person".

You fully know that your statement (in bold) is total bullshit. The issue i have is that this patch is probably going to be blindly crammed into distributions that might have a 0.1% percentage server usage (the patch should not be applied in those cases). The only way to stay out of this insanity is by making your own distribution. That's not something i want to do or will ever do on my own. I'm merely stating that some distributions "should" apply it (say the server orientated distributions), but most others should not. And they should not be pushed into applying it out of bad press fears. Now i don't know if Arch (my distro of choice) is going to apply it, i hope not. It would be silly of them as it's not intended to be used as server OS.

And yeah, if i were to get the 10k for a bug bounty i'd probably do it too. But i would not make a movie trailer for it!

[Volta]

in this case with extremes of 90% performance loss. The average case seems more closely to 10-20%. That's not worth it for consumer and programmer aimed distributions. Or anything non server related. So distributions like Fedora, Arch, Ubuntu, Suse, Clear, .. should not apply this.

Mind you, even Intel says that this leak is very difficult to abuse.

I think Intel is not a reliable source. However, if some mitigation compiler flags may affect AMD CPUs performance then I'm voting for not enabling this. AMD shouldn't suffer at all from Intel's mistakes. I'm an 'unhappy' owner of i7 3770k. It served well, but my next one will be AMD for sure.

[tildearrow]

Ready to downgrade your microcode? Ready to remove mitigation patches from compilers and to recompile everything with appropriate flags?

I have not upgraded my microcode since November 2017.

Ugh, yeah, I hope Arch Linux does not enable LVI mitigation in their packages... That'd force me to use Gentoo ,-,