GNU Assembler Adds New Options For Mitigating Load Value Injection Attack
Yesterday the Load Value Injection (LVI) vulnerability was disclosed by Intel and researchers and affecting newer Intel CPUs with SGX and requiring mitigations outside of all the speculative execution mitigations the past two years. The GNU Assembler patches adding new options for mitigation have now been merged to Git master.
As outlined yesterday, the LVI mitigations noted by the researchers would be inserting LFENCE barriers before every vulnerable load instruction. That amounts to what has been merged today for the GNU Assembler (Gas), but it's not enabled by default and there is control over where the lfence barriers should be inserted.
Added are -mlfence-after-load=yes for generating an LFENCE after load instructions, -mlfence-before-indirect-branch=none|all|memory|register for calling the instruction before indirect branches, and -mlfence-before-ret=or|not for lfence usage before return (ret) instructions.
None of these switches are enabled by default and obviously there is a performance cost involved... We'll be running our own benchmarks shortly for seeing the involved performance cost of these GNU Assembler options for using Load Fence much more frequently.
There was also talk of Intel releasing updated CPU microcode for helping with LVI/CVE-2020-0551 but so far we haven't seen any update. In fact, the latest Intel CPU microcode updates for Linux are from last November following the JCC Erratum disclosure. We still haven't seen updated CPU microcode surface on Linux for January's CacheOut / L1D Eviction Sampling disclosure where microcode mitigations were talked about. Once that new Intel CPU microcode does surface, we'll see how that shifts the performance from the mitigations so far this year.
Update: Benchmark results of the GAS mitigation options.
As outlined yesterday, the LVI mitigations noted by the researchers would be inserting LFENCE barriers before every vulnerable load instruction. That amounts to what has been merged today for the GNU Assembler (Gas), but it's not enabled by default and there is control over where the lfence barriers should be inserted.
Added are -mlfence-after-load=yes for generating an LFENCE after load instructions, -mlfence-before-indirect-branch=none|all|memory|register for calling the instruction before indirect branches, and -mlfence-before-ret=or|not for lfence usage before return (ret) instructions.
None of these switches are enabled by default and obviously there is a performance cost involved... We'll be running our own benchmarks shortly for seeing the involved performance cost of these GNU Assembler options for using Load Fence much more frequently.
There was also talk of Intel releasing updated CPU microcode for helping with LVI/CVE-2020-0551 but so far we haven't seen any update. In fact, the latest Intel CPU microcode updates for Linux are from last November following the JCC Erratum disclosure. We still haven't seen updated CPU microcode surface on Linux for January's CacheOut / L1D Eviction Sampling disclosure where microcode mitigations were talked about. Once that new Intel CPU microcode does surface, we'll see how that shifts the performance from the mitigations so far this year.
Update: Benchmark results of the GAS mitigation options.
14 Comments