Google Engineer Shows "SESES" For Mitigating LVI + Side-Channel Attacks - Code Runs ~7% Original Speed

Disclosed last week was the Load Value Injection attack affecting Intel CPUs and requiring new mitigations. While the GNU Assembler mitigation options were quickly added, on the LLVM toolchain side the developers there continue evaluating the proposed LVI mitigation along with another option that looks to mitigate more than just LVI. The "SESES" proposal looks more broadly at mitigating CPU side-channel vulnerabilities but with shattering performance hits.

As we outlined when benchmarking the GNU Assembler mitigations for LVI, the software mitigation impact can be quite significant. The assembler work is adding an LFENCE barrier instruction around loads, indirect branches, and RET instructions. The tests on Kabylake found that the mitigated performance overall was about 22% that of the performance without the LVI mitigations.

While performing at just ~22% the original performance is already a brutal hit, an LLVM mitigation proposed by a Google engineer in working to avoid LVI and other side-channel vulnerabilities in one of her tests saw just ~7% the original performance based on the geometric mean. That LLVM work with the even more dramatic hit is the Speculative Execution Side Effect Suppression (SESES) and was started for mitigating Load Value Injection but expanded to address other side-channel vulnerabilities like Spectre V1/V4 and others. It offers extra safeguards beyond just LVI mitigation, but in Google's own BoringSSL test (their fork of OpenSSL), the performance came in to a 7% geometric mean of the original performance (not a 7% hit, merely 7% the original performance).

With the potential impact from opting into SESES, you may be better off finding other uses for your computer.

The SESES pass for LLVM inserts an LFENCE before every memory read instruction, memory write instruction, and at the first branch instruction in a group of terminators at the end of a basic block. Google engineer Zola Bridges worked on the patch and commented, "The goal is to prevent speculative execution, potentially based on misspeculated conditions and/or containing secret data, from leaking that data via side channels embedded in such instructions. This is something of a last-resort mitigation: it is expected to have extreme performance implications and it may not be a complete mitigation due to trying to enumerate side channels."

Meanwhile Intel has separate proposed hardening for LVI. That patch is similar in nature to the GNU Assembler work on inserting extra LFENCE instructions. No performance numbers were provided with that pending Intel LVI mitigation for LLVM but obviously would be better off than the extreme SESES.

Both patch series remain under review. Neither patch series is looking to enable their behavior by default but would be opt-in for those wanting to mitigate against LVI. Also keep in mind these mitigations are just for the LLVM toolchain while already the LVI mitigations have landed in GAS on the GNU side and there is no SESES equivalent pass being talked about on that side of the table for now.