L1 Terminal Fault / CVE-2018-3615 , CVE-2018-3620,CVE-2018-3646 / INTEL-SA-00161

Severity and Score

Aliases

• Foreshadow

Related Content

INTEL-SA-00161

Additional resources and response to L1 Terminal Fault

Microcode revision guidance

List of processors potentially affected by L1 Terminal Fault

Details on Intel's microcode update process

Overview

When a program attempts to access data in memory, the logical memory address is translated to a physical address by the hardware. Accessing a logical or linear address that is not mapped to a physical location on the hardware will result in a terminal fault. Once the fault is triggered, there is a gap before resolution where the processor will use speculative execution to try to load data. During this time, the processor could speculatively access the level 1 data cache (L1D), potentially allowing side-channel methods to infer information that would otherwise be protected.  

This side-channel method can be exploited in three different environments: 

• L1 Terminal Fault-SGX (CVE-2018-3615)—Systems with microprocessors utilizing speculative execution and Intel® Software Guard Extensions (Intel® SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via side-channel analysis.
• L1 Terminal Fault-OS/SMM (CVE-2018-3620)—Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and side-channel analysis.
• L1 Terminal Fault-VMM (CVE-2018-3646)—Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and side-channel analysis.

Impact Summary

• Malicious applications may be able to infer the values of data in the operating system memory, or data from other applications.
• A malicious guest virtual machine (VM) may be able to infer the values of data in the VMM’s memory, or values of data in the memory of other guest VMs.
• Malicious software running outside of SMM may be able to infer values of data in SMM memory.
• Malicious software running outside of an Intel® SGX enclave or within an enclave may be able to infer data from within another Intel SGX enclave.
   

Mitigation

Check which capabilities your processor supports prior to applying mitigations. Details can be found in CPUID Enumeration and Architectural MSRs.

Intel has released new microcode for many processors affected by L1TF. This modifies some operations to implicitly remove data from the L1D during certain privilege transitions. It also provides a method by which software can explicitly flush the L1D by writing 1 to bit 0 of a new model specific register, IA32_FLUSH_CMD (MSR 0x10B). System manufacturers and system software vendors provide these microcode changes via BIOS updates.

While these microcode updates provide important mitigation during enclave entry and exit, updated microcode by itself is not sufficient to protect against L1TF. Deploying OS and VMM updates is also required to mitigate L1TF.

OS and driver developers

Whether the operating system (OS) is running on bare-metal or as a virtual machine, the OS is responsible for mitigating against exploitation of paging structure entries (PTEs) by malicious applications. To do this, the OS can ensure vulnerable PTEs refer only to specifically-selected physical addresses, such as those addresses outside of available cached memory or addresses that do not contain secrets.

There are four typical cases that need mitigation in an OS:

1. Pages with no valid mappings.

2. Pages written to other storage (swapped out), such as when the OS is short of memory.

3. Pages where the application has requested the OS disable access.

4. Pages in transitional states where the operating system needs to temporarily block access.

For full details on these, go to Intel Analysis of L1 Terminal Fault. 

If you are an OS developer working with System Management Mode (SMM), review the SMM section in Intel Analysis of L1 Terminal Fault for guidance on whether further assessment of your SMM is suggested. CPUID Enumeration and Architectural MSRs provides further insight.
 

Virtual machine monitor developers

VMMs require some similar mitigations as OSes, but there are additional challenges relating to the guest view of MAXPHYADDR and interactions between logical processors on hyperthreading-enabled systems.

When guests are trusted or belong to the same security domain, no mitigation is needed. However, VMMs generally allow untrusted guests to place arbitrary translations in the guest paging structure entries because VMMs assume any entries will be translated with VMM-controlled EPT. But EPT translation is not performed in the case of an L1 terminal fault.

This means a malicious guest OS may be able to set up values in its paging structure entries that attack arbitrary host addresses, theoretically enabling an exploit to access any data present in the L1D on the same physical core as the malicious guest. For this reason, VMM mitigations are focused on ensuring secret data is not present in the L1D when executing guests. For full details on these, go to Intel Analysis of L1 Terminal Fault.

​Both the VMM and the guest OS may have mitigations for L1TF, so they should avoid actions that interfere with each others’ mitigations. The VMM should not trust the guest is performing any particular mitigation, but should follow the conventions described in the VMM Assistance for Guest OS Mitigations section of Intel Analysis of L1 Terminal Fault to avoid interfering with any guest mitigations.

Mitigations in nested VMM environments require the first level VMM to check the MSRs of the nested VMMs and vice versa. Refer to the Nested VMM Environments section in Intel Analysis of L1 Terminal Fault for further details.

Developers of software running in an enclave

For background on how L1TF can affect software running in an enclave, go to Intel Analysis of L1 Terminal Fault. 

For Intel SGX mitigation, users should apply the latest microcode update through BIOS updates and confirm they have the latest version of Intel SGX software installed.

The L1TF and its subvariant enclave-to-enclave (E2E) attacks may be able to reveal code or data within an enclave. Processors that load the latest microcode update from a platform manufacturer BIOS update can prevent malicious users from applying L1TF or E2E to infer values of an enclave on the same logical processor. Intel will be invoking the Intel SGX Trusted Computing Base recovery process to assist with the mitigation of L1TF and E2E for Intel SGX. The microcode update changes the Security Version Number (SVN) associated with the Intel SGX implementation and provides enclaves on the platform with new sealing and attestation keys. 

With the microcode update, the Intel SGX attestation will indicate whether hyperthreading has been enabled by the BIOS. When hyperthreading is disabled or not supported, the microcode update fully mitigates L1TF and E2E for Intel SGX. Intel SGX does not require changes to OS paging structures or VMM behavior to achieve this protection.

When hyperthreading is enabled, the possibility of L1TF or E2E attacks from the sibling logical processor still exists before the enclave secret in L1 data cache is flushed or cleared. The entity verifying the attestation might reject attestations from a hyperthreading-enabled system if it deems the risk of potential L1TF or E2E attacks from the sibling logical processor as not acceptable. 

Note: Intel SGX enclave secrets encrypted with enclave keys when hyperthreading has been disabled cannot be decrypted when hyperthreading is enabled.

System Administrators

Always keep your systems up to date with the latest security updates and guidance from your OS and VMM vendors.

References

• Introduction to Speculative Execution Side Channel Methods
• Intel Analysis of Speculative Side Channels
• Speculative Execution Side Channel Mitigations
• Intel Analysis of L1 Terminal Fault
• List of processors affected by L1 Terminal Fault
• Microsoft* response
• Linux* kernel documentation

Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources