If Mitigations Weren't Already Bad Enough: Slow Build Times Now Lead To An Unoptimized Intel 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.
31 Comments
