A group of researchers from the University of Virginia and the University of California presented a new type of attack on the microarchitectural structures of Intel and AMD processors, identified during reverse engineering of undocumented CPU capabilities. The proposed attack method involves the use of an intermediate micro-op cache in processors, which can be used to retrieve information accumulated during speculative execution of instructions.
For optimization purposes, the processor begins to execute some instructions in speculative mode, without waiting for previous calculations to complete, and if it then determines that the prediction was not justified, it rolls back the operation to its original state, but the data processed during speculative execution is deposited in a cache, the contents of which can be determined.
It is noted that the new method significantly outperforms the Specter v1 attack, makes the attack difficult to detect and is not blocked by existing methods of protection against side-channel attacks designed to block vulnerabilities caused by speculative execution of instructions (for example, the use of the LFENCE instruction blocks leaks in the last stages of speculative execution , but does not protect against leakage through microarchitectural structures).
The method affects Intel and AMD processor models released since 2011, including the Intel Skylake and AMD Zen series. Modern CPUs break complex processor instructions into simpler RISC-like micro-operations, which are cached in a separate cache. This cache is fundamentally different from higher-level caches, is not directly accessible and acts as a stream buffer for quick access to the results of decoding CISC instructions into RISC microinstructions. However, researchers have found a way to create conditions that arise when cache access conflicts and allow one to judge the contents of the micro-operation cache by analyzing differences in the execution time of certain actions.
The micro-operation cache in Intel processors is segmented in relation to CPU threads (Hyper-Threading), while AMD Zen processors use a shared cache, which creates conditions for data leakage not only within one execution thread, but also between different threads in SMT (possible data leakage between code running on different logical CPU cores).
Researchers have proposed a basic method for detecting changes in the micro-operation cache and several attack scenarios that allow creating hidden data transmission channels and using vulnerable code to leak confidential data, both within a single process (for example, to leak process data when executing third-party code in engines with JIT and in virtual machines), and between the kernel and processes in user space.
When organizing a variant of the Specter attack using a micro-operation cache, researchers were able to achieve performance of 965.59 Kbps with an error rate of 0.22% and 785.56 Kbps when using error correction, in the case of organizing a leak within the same address space and privilege level. With a leak spanning different privilege levels (between kernel and userspace), performance was 85.2 Kbps with error correction added and 110.96 Kbps with an error rate of 4%. When attacking AMD Zen processors, creating a leak between different logical CPU cores, the performance was 250 Kbps with an error rate of 5.59% and 168.58 Kbps with error correction. Compared to the classic Specter v1 method, the new attack was 2.6 times faster.
It is expected that protecting against a micro-op cache attack will require changes that will reduce performance more than if you enabled Specter attack protection. As an optimal compromise, it is proposed to block such attacks not by disabling caching, but at the level of monitoring anomalies and identifying cache states that are typical for attacks.
As in Specter attacks, organizing a leak from the kernel or other processes requires the execution of a certain sequence of commands (gadgets) on the side of the victim processes, leading to speculative execution of instructions. About 100 similar gadgets have been found in the Linux kernel, which will be removed, but workarounds for their generation are periodically found, for example, related to running specially designed BPF programs in the kernel.
Source: opennet.ru