If Mitigations Weren't Already Bad Enough: Slow Build Times Now Lead To An Unoptimized Intel LVI Pass
Written by Michael Larabel in LLVM on 11 June 2020 at 08:38 AM EDT. 32 Comments
LLVM --
Disclosed back in March was the LVI attack (Load Value Injection) affecting Intel CPUs. Mitigating LVI requires compiler toolchain changes and LLVM 11 merged its LVI mitigation last month that adds a load fence after each instruction that may be vulnerable to this attack, similar to the GNU Assembler changes. Now though LLVM is adding an unoptimized version of their LVI pass.


The existing LVI mitigations on the GNU and LLVM sides already have some performance overhead involved as a result of the added LFENCEs. So why is an unoptimized version now being added as another option to LLVM? It turns out the (optimized) version added is too detrimental to compile/build times where as with this less optimized version, code can compile quicker so it's less of a build regression.

This LVI unoptimized version is in turn intended to be used when compiling code at the -O0 optimization level.... For the higher optimization levels or when not caring about compile times, the existing optimized version is intended when passing the appropriate flag.

This unoptimized version stems from that the added complexity of the Load Value Injection hardening was causing noticeable slowdowns for -O0 builds. One example cited was SQLite building 1.5% slower with that LVI hardening in place. It was discussed to disable LVI load hardening at -O0 but it was decided to side with security over disabling said hardening.

So merged yesterday was this unoptimized version that has "equal security properties, but without any optimizations (and more importantly, without the need for expensive analysis dependencies)." It will be interesting now to see the unmitigated vs. default mitigation vs. unoptimized mitigation performance for binaries regarding Load Value Injection. With -O0 principally used for debug/testing builds, at least end-users shouldn't be impacted by this unoptimized pass but it will make the already optimized-less binaries even slower for said purposes.
Related News
About The Author
Author picture

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter or contacted via MichaelLarabel.com.

Popular News This Week