The Brutal Performance Impact From Mitigating The LVI Vulnerability

OpenSSL signing performance dropped to nearly a tenth of its original performance when making use of LFENCEs after loads.

Google's LevelDB was significantly impacted with operations taking nearly twice as long.

PostgreSQL performance was also hit significantly.

The results of these benchmarks are quite staggering but, fortunately, most users probably don't need to rebuild all of their software packages with these assembler-based mitigations. It may make sense for any security-sensitive applications and those running public services / potentially untrusted code and particularly those interacting with Intel SGX but there are differing views currently over the real-world prospects of an LVI attack vector. At least that would be the guidance for now. What's worrisome is that if there are any more broad transient execution flaws based on LVI to be discovered (or to be publicly disclosed) that could end up necessitating this increased LFENCE usage to become more widespread considering how we have seen these microarchitectural vulnerabilities build up over time. But at least for now only the most concerned security concious end-users should be using these mitigation options or enterprises where Intel SGX is more widely used and public clouds, etc. LVI isn't gauged as a very practical attack at least according to Intel and some university researchers, but Bitdefender who co-discovered LVI say it could be used as a basis for future real-world attacks and as shown by these benchmarks the performance is another troubling set-back if these options need to be used liberally when compiling software.

The performance impact from these LVI mitigation switches are likely the largest we've seen since we began benchmarking the security mitigations following Spectre and Meltdown. The LVI mitigation impact is of similar scope to last year's JCC Erratum in that pure user-space applications can be affected and not contingent upon frequent context switching or other specific kernel interaction. Going LFENCE-happy understandably takes a big toll on performance and we hope the guidance doesn't change stemming from any future disclosures that would need to make using these assembler options more recommended. Of the three assembler options, the most impactful is the issuing of an LFENCE after every load instruction while having the extra LFENCE instructions before indirect branches and before ret instructions were also measurable. Thankfully the very latest Intel CPUs such as newer Coffee Lake parts, Comet Lake, and Cascade Lake are said to be largely unaffected while Ice Lake is not vulnerable at all.