It has been over two years since the original revelations of the Meltdown and Spectre vulnerabilities in various CPUs but especially Intel processors. These vulnerabilities went after how speculative execution could allow a CPU to access information in an unsecure way, potentially allowing it to leak to an attacker. Though the mitigations, both software and hardware, have been implemented for a while now, it turns out switching things around a bit can get around some of them. University researchers at several universities and Bitdefender independently realized an attack could be made that instead of trying to get information out of a CPU, it could insert information into it. The code can be detected and then all operations be rolled back, but for a time an application will run with the injected code. Intel was notified of the discovery in April 2019 by the researchers and the discovery was kept under embargo until this week. Bitdefender made its discovery in February 2020.
This new attack is called Load Value Injection, LVI, and even though it is taking advantage of Spectre-style code gadgets and Meltdown-type illegal data flow, none of the mitigations for those vulnerabilities apply. The researchers specifically considered the attack against Intel Software Guard eXtensions, SGX, which is meant to provide a secure enclave for information within memory, and found LVI to be successful on almost all processors that use it. While it was only SGX the researchers targeted, the researchers believe it could be applied to other software, such as non-SGX traditional cross-process, cross-virtual-machine, or user-to-kernel environments because the principles to LVI are not limited to SGX.
The way the attack works is to insert a piece of malicious code into a hidden processor buffer. By triggering a faulting or assisted load, the malicious code can be picked up and executed. Depending on the specific code, it could directly encode secrets the attacker can access or facilitate a second-stage attack. The CPU will eventually discard the computations of the attack code once it discards the faulting or assisted load, but this may leave it in a micro-architectural state that side-channel analysis can get information from.
The new Icelake processors do have hardware mitigations in place that work, and some other CPUs have partial mitigations leaving them only partially vulnerable. As far as CPUs from other vendors, such as AMD, are concerned, the researchers are assuming that any processor vulnerable to Meltdown-type data leakage can be vulnerable to LVI, but only tested against Intel SGX-using processors.
For impacted CPUs, there are possible software mitigations, but they come at a significant performance cost. The mitigation is to explicitly add lfence speculation barriers into every potentially vulnerable load. This involves patching compilers and will result in serializing the processor pipeline, so the researchers predict that some workloads could be slowed by a factor of 2 to 19, but of course the real-world may differ from these predictions. Though Intel does not believe LVI attacks are practical, one of their open-source compiler developers added mitigation options to the GNU Assembler and Phoronix decided to put them to the test, to have some real numbers for how much an impact there can be. The site used a server using a Xeon E3-1275 v6 Kabylake processor for its testing.
Spoiling the final result, the geometric mean of the test results gave a score of 598.92 without an mitigations, but when having lfence issued after every load instruction resulted in a score of 138.28, which is 23% and higher is better here. Other options, like issuing lfence before indirect branches and before ret instructions also showed an impact to performance, but not nearly to the same degree. Ultimately the advice is to only recompile applications with these flags if they are security sensitive. So long as the likelihood of LVI attacks is low, this may be enough, but if additional vulnerabilities based on it are disclosed, this may change.
Getting to some specific results, some media related applications saw a large performance drop, but these are also applications that might not need it. The tests for GraphicsMagick rotating images saw a drop to 22% from no mitigations to having lfence applied after each load, and a drop to 14% for resizing. For video encoding, the x264 encoder went from 44.54 FPS without mitigations to 10.81 FPS, 24% the original speed, while vp9 encoding with libvpx dropped from 23.89 FPS to 2.63 FPS (11%), Intel's SVT-HEVC encoder went from 24.41 FPS to 3.88 FPS (16%), while the SVT-AVI encoder dropped from 13.841 FPS to 2.169 FPS (16%) and the dav1d decoder went from 281.07 FPS to 85.95 FPS (31%). Media applications should not need to be re-compiled with the mitigations though, and hopefully that will not need to change.
Phoronix also tested using C-Ray and saw the time to complete jump from 160.75 seconds to 1234.59 s (768%). Converting a WAV file to FLAC suffered an increase from 8.922 s to 97.941 s (1098%). The OpenSSL benchmark went from 1217.6 signs per second to just 138.1 (11%) and PostgreSQL fell from 109,133.83 TPS to 49,296.66 (45%) in its benchmark.
If you are curious, it is definitely going to be worth looking through the Phoronix article on its testing, which is the Phoronix [2] link below. It will also prove interesting to watch if more attacks appear, forcing these mitigations to be applied to more software, and if non-Intel CPUs also prove vulnerable.
Source: Phoronix [1] (LVI Attack Description), [2] (Mitigation Performance), LVIAttack.eu, and Intel
