CVE-2020-0550 - Snoop Assisted L1D Sampling

Executive Summary

Red Hat is aware of a microarchitectural (hardware) implementation issue that could allow an unprivileged local attacker to bypass conventional system security controls to infer on-CPU Level 1 cache contents.

At this time, this specific flaw is only known to affect Intel-based processors. This flaw is hardware-based and investigation into this flaw is ongoing.

The Snoop Assisted L1D Sampling flaw has been assigned CVE-2020-0550 with a security impact of Moderate.

Technical Details and Background

A flaw was found in the CPU’s microarchitecture structures similar to previous speculation-attack vulnerabilities that impact Intel microprocessors.

What is snooping ?

Snooping, bus snooping, or bus monitoring refers to a cache-coherence mechanism used by systems to ensure data consistency of information stored in multiple system-wide caches. Caches are accessed via a shared medium (e.g. a bus connection) and thus cache controllers can “snoop” (monitor) the medium for access to shared data.

How is snooping used?

Modern systems have multiple cores and CPUs have a separate on-die cache per physical core. To improve performance, a system may maintain multiple copies of shared data in different levels of cache, usually a copy in system memory and another in the local cache of each processor using the memory.

When a processor modifies its local copy, changes must propagate to each level of cache (memory) where the values are in use. Cache coherence is the practice of ensuring that the cached values are consistent and changes are reflected across each level of cache.

The coherence can be achieved by "bus snooping". Devices that use system memory can monitor transactions (snoop) on the system memory bus. If a transaction modifying a memory location used by one of these devices appears on the bus, each device will update their local shared copy of the data to match the new value.

What is the flaw ?

Under a set of precisely coordinated conditions, data in a modified cache line, which is being updated in response to a snoop, can be inferred by an attacker. During the same clock cycle as the snoop, the attacker can trigger a faulting 'load-assist' or a TSX asynchronous aborting load on another core, which encodes the data from the snoop into the cache. The attacker can then use a traditional cache analysis technique (such as Flush+Reload) to recover the data.

This flaw is different from L1D Eviction Sampling (CVE-2020-0449). Snoop-assisted L1D sampling requires the snoop to read the modified cache line in the same single core clock cycle window as the faulting/assisting/aborting load. This window of opportunity is very narrow.

Disabling TSX as shown in the TAA kcs article, provides some protection against exploitation, but does not completely mitigate the flaw.

Attack vector - Operating system

Only data that is actively modified in the CPU L1 data cache is vulnerable to this attack. Snoop-assisted L1D sampling does not allow a local attacker to specify which cache-line the system will attempt to flush to infer. This requires more precise timing between the snoop and measure operations than previous flaws such as L1TF.

Attack vector - Virtual Machine

Previous L1TF mitigations issue assembly commands to clear affected microarchitectural state to prevent attackers from being able to use these attacks between 'host and guest' and 'guest to guest'.

When the host has correctly applied L1TF mitigations, the sensitive memory contents of the virtual machines will not be in the L1D cache when a possibly malicious VM attempts to attack them.

At this time there are no known exploits capable of launching an attack in this manner.

Mitigation

Due to the high level of difficulty of the attack and the performance impact which would be associated with any potential mitigations, there are currently no microcode or software mitigations for this issue, other than the existing L1TF mitigations described above, which protect virtual machines against other virtual machines on the host; and disabling TSX, as described above, which can raise the bar of difficulty of the attack.

Red Hat doesn't currently have knowledge of any real-world occurrences of this attack, so the risk of attack may be considered low. To further minimize the possibility of attacks related to this and other speculative issues, trusted and untrusted workloads can be isolated on separate systems.

Frequently Asked Questions

Q: How can I determine if my system is affected ?
A: Consult the list of affected CPU’s below:

• Legacy Intel Core Processors (Sandy Bridge)
• Intel Xeon Processor family v2 (Sandy Bridge)
• Intel Xeon Processor family v3 (Haswell)
• Intel Xeon Processor family v4 (Broadwell)

Acknowledgements

Red Hat thanks Intel and industry partners for reporting this issue.