My current understanding is that the microcode update changes the
behavior of the obsolete VERW instruction so that it causes a flush of
various internal processor buffers
The new behavior of the
VERW instruction is described in this article. In particular:
VERW instruction retains the same existing functionality, i.e., it checks whether the specified segment is writable from the current privilege level.
- Only the memory-operand variant of the instruction is guaranteed to overwrite the buffers exploited by MDS. The register-operand variant may or may not perform the buffer overwriting functionality.
- The buffer overwriting functionality occurs regardless of the result of the segment write permission check (including an exception).
VERW instruction execution by itself does not prevent later instructions from being executed before all of the MDS-affected buffers are overwritten. Therefore, it's necessary to place a serializing instruction (Intel calls a speculation barrier) after
VERW. Consider the example from the same article:
Code region A (victim accessing secret data)
Code region B (victim accessing data that is not secret)
Speculation barrier (for example, LFENCE)
Code region C (attacker can only see the data accessed in B)
Assume that these instructions are being executed on a processor with the
MD_CLEAR microcode update (discussed below). The execution of A may leave some secret in-flight data on the same physical core. When
VERW begins execution, B may execute before all the leaky buffers are overwritten. A barrier, such as
LFENCE, need to be placed after B to ensure that C cannot access the secret data.
VERW instruction is not supported in real mode and virtual-8086 mode because segment access permissions are not available in these modes. Therefore, in these modes, a sequence of instructions, which depends on the microarchitecture, needs to be used instead.
The following characteristics of
VERW explain why Intel chose to overload that instruction with the buffer overwriting functionality (instead of any other instruction or introducing a new MSR):
VERW is microcoded, which is probably necessary for a microcode update to work.
VERW is rarely used, so the resulting performance overhead is practically insignificant on existing software.
VERW can be executed at any privilege level. In particular, it can be used in cases where the security boundaries are in user mode (e.g., SGX and sandboxes).
VERW is not perfect though. As already said above, it doesn't work in real mode and virtual-8086 mode. It also modifies the
CVE-2018-12130 (MFBDS) can only be partially mitigated by disabling
SMT, according to an in-depth blog post. Some information can still be
leaked through a context switch during syscalls.
There are two cases that need to be considered separately:
- The attacker and the victim never run on two threads of the same physical core at the same time. This can occur when HT is disabled or when the OS scheduler decides to run the threads on different physical cores at the same time (because, for example, the threads have different physical core affinities). Either way, the threads may still run on the same logical core at different points in time. An MDS exploit can still be successful. The only way for the attacker to run on the same logical core as the one the victim run on is when the victim switches to kernel mode (e.g., system call or hardware interrupt) and the attacker gets scheduled to run next on the same logical core. Therefore, the kernel can fully prevent the attacker from exploiting the internal CPU buffers by executing the
VERW instruction before returning to user mode (to run next whatever thread is scheduled on that logical core). This also ensures that the buffers contain no memory requests from the kernel when returning to user mode. Similarly,
VERW needs to be executed when switching between two virtual machines on the same logical core.
- The attacker and the victim may run concurrently on the same physical core. The Linux kernel documentation on MDS mentions that HT needs to be disabled for full protection to prevent this particular situation from occurring in the first place. The Intel article on MDS, however, proposes an alternative mitigation called group scheduling. The idea here is to ensure that two threads are scheduled to run on two sibling logical cores only if they mutually trust each other. The Hyper-V hypervisor already employs group scheduling (and it has been recently updated to use
VERW when switching between virtual processors that belong to different VMs). During the execution of
VERW (or the alternative software sequence), the sibling logical core must be quiesced (e.g., execute
PAUSE) to ensure that all the buffers get overwritten.
The aforementioned mitigations (overwriting the MDS-affected buffers when returning from the kernel or when switching between VMs, disabling HT, and group scheduling) cannot protect sandboxed applications (in a web browser) and SGX enclaves, where there is no switching between privilege levels. One possible mitigation for sandboxed apps is using processes instead. SGX enclaves are protected by the microcode update itself.
MD_CLEAR microcode update seems to include the following changes:
- New functionality to the
VERW instruction as discussed above. Only the buffers that are vulnerable on each particular processor are overwritten, so the impact of
VERW on performance depends on the processor. On processors that are not vulnerable to any MDS attack (such as 2nd Gen Xeon SP),
VERW doesn't overwrite any buffers and behaves as usual.
- When entering or exiting an SGX enclave, the MDS-affected buffers are overwritten. However, on entrance to the enclave, it must ensured that no untrusted thread runs on the sibling logical core.
- When exiting system management mode (using the
RSM instruction), the MDS-affected buffers are overwritten. However, on entrance to SMM mode, the SMM software must ensure that no untrusted thread runs on the sibling logical core.
- The RIDL paper in Section IX mentions that "The updated microcode also flushes these buffers when flushing the L1 cache." I think this refers to the
IA32_FLUSH_CMD MSR, where setting the bit at index 0 to 1 causes the processor to writeback and invalidate the whole L1D cache. This is referred to as the
L1D_FLUSH command. It also overwrites all buffers that are vulnerable to MDS.
In this Intel article, the performance impact of the microcode update and OS patch (to use the
VERW instruction) appears to me to be significant (over 5%) for some benchmarks. There is also a list of FAQs at end where Intel recommends to not disable HT, which makes sense.
Section E of the RIDL paper mentions that the authors were able to leak physical addresses from the page walking hardware of the MMU (page walks go through the LFBs). I've not seen any proposed mitigations for this attack.
Some recent processors include hardware mitigations for all of the four MDS attacks. This can be checked using the following sequence of commands:
sudo modprobe msr
sudo rdmsr -p 0 0x10A
The first command loads the
msr kernel module and the second command reads the value in the
IA32_ARCH_CAPABILITIES MSR. If the sixth bit (bit at index 5) is 1, the processor has hardware mitigations for all MDS attacks, and so all of the mitigations discussed above are not needed. This bit is called
MDS_NO. Otherwise, the processor has no hardware mitigations for at least MSBDS, MLPDS, and MDSUM. Note that if the
IA32_ARCH_CAPABILITIES MSR itself is not supported, then the processor definitely has no hardware mitigations for all MDS attacks.
For discussion on how MFBDS, MLPDS, and MDSUM work, see: About the RIDL vulnerabilities and the “replaying” of loads. For discussion on how MSBDS works, see: What are the microarchitectural details behind MSBDS (Fallout)?.