L1 Terminal Fault (L1TF)
CVE-2018-3615 (also known as Foreshadow), CVE-2018-3620, and CVE-2018-3646
Raoul Strackx, Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F. Wenisch, Yuval Yarom, and researchers from Intel discovered that memory present in the L1 data cache of an Intel CPU core may be exposed to a malicious process that's executing on the CPU core. If a victim process and malicious process are scheduled on the same core, the malicious process could access contents of the L1 data cache that pertain to the victim process. Hyper-Threads, also known as Symmetric Multi-Threading (SMT), make it easier to exploit L1TF since sibling Hyper-Threads belong to a single CPU core and share the same L1 data cache. Unintended memory exposure can occur between userspace processes, between the kernel and userspace, and between virtual machines, and between a virtual machine and the host environment.
Processors from other vendors are not known to be affected by L1TF.
Three CVEs have been assigned to this issue:
CVE-2018-3615 for Intel Software Guard Extensions (Intel SGX)
CVE-2018-3620 for operating systems and System Management Mode (SMM)
CVE-2018-3646 for impacts to virtualization
Ubuntu users are recommended to update to the latest kernel and intel-microcode packages. Updated kernels provide a software fallback mechanism for processors that will not receive microcode updates from Intel.
Consult the Ubuntu Security Notices below for version information:
Users who are unable to reboot into an updated kernel may be interested in the smt snap that can be used to disable Hyper-Threading. Please see its documentation for details. Disabling Hyper-Threading, without rebooting into an updated kernel, does not provide full mitigation for L1TF but it does make it more difficult to exploit. Updating to the latest kernel and rebooting is recommended.
The techniques used to provide remediation for these issues vary. A summary, for each of the three attack scenarios, is provided in the following subsections. Additionally, the Linux kernel documentation provides full details on configuration options available.
This issue does not affect Ubuntu. See the references below to find information from Intel for L1TF mitigations for Intel SGX.
This issue is fully mitigated by Ubuntu kernel updates. The updates remove the possibility for unintended memory exposure between processes within the same operating system environment by adjusting page table entries for not-present pages to point to uncacheable memory. The mitigation for this vulnerability introduces negligible performance impacts.
This issue is partially mitigated by Ubuntu kernel and intel-microcode updates but controls are available to fully mitigate it in situations where complete protection is required. This issue only affects virtualization hypervisors and does not impact systems where virtualization is not used. Mitigations provided by the Ubuntu kernel are specific to KVM in the Linux kernel. Consult your hypervisor vendor if you're using another hypervisor.
By default, updated Ubuntu kernels will flush the L1 data cache in some specific scenarios when the host enters the guest. Flushing the L1 data cache is an expensive operation that negates the performance improvements of caching so flushing the L1 data cache is performed selectively to protect certain code paths that could cause unintended memory exposure to a malicious guest.
Optimized L1 data cache flushing is available via intel-microcode updates. The updated kernels implement a software fallback cache flushing mechanism for processors that have not received microcode updates.
Configuration options are available to deviate from the default L1 data cache flushing behavior and either always perform a cache flush or never perform a cache flush when entering a guest. Always flushing the cache will negatively impact performance in a manner that's dependent on the workload inside of the virtual machine while never flushing the cache will make your system vulnerable to CVE-2018-3646. Use the "kvm-intel.vmentry_l1d_flush=always" or "kvm-intel.vmentry_l1d_flush=never" kernel command line options to change the default persistently across reboots. Write "always", "cond" (the default), or "never" to /sys/module/kvm_intel/parameters/vmentry_l1d_flush to temporarily change the behavior.
Processors that support Hyper-Threads introduce an additional attack surface that must be considered since mitigation is not enabled by default. It is possible that a malicious guest could read secrets stored in memory by the host (userspace or kernel) or another guest if the two operating system environments simultaneously run on sibling Hyper-Threads from the same CPU core.
Full protection from the Hyper-Thread based attack can be achieved in one of two ways. The first option requires that Hyper-Threads be disabled in the system's BIOS, by booting with the "nosmt" kernel command line option, or by writing "off" or "forceoff" to /sys/devices/system/cpu/smt/control (this file is not persistent across reboots). The second option involves restricting guests to specific CPU cores that are not shared with the host or other guests considered to be in different trust domains. This option is more difficult to configure and may still allow a malicious guest to gain some information from the host environment.
OpenStack administrators will want to ensure that guests running in separate trust domains do not execute on sibling Hyper-Threads by using one of the options described above.
Checking System Status
Updated Ubuntu kernels have the ability to report how the system is currently affected by L1TF. To check your system, read the contents of the /sys/devices/system/cpu/vulnerabilities/l1tf file. You must apply kernel updates and reboot if the file does not exist as that indicates that your kernel does not have mitigations in place for L1TF.
Processors that aren't vulnerable to L1TF will report the following:
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Not affected
The file will contain the following contents for processors that do not support Intel Hyper-Threading or where Hyper-Threading has been disabled:
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
Processors that have Hyper-Threading support enabled will indicate that SMT is vulnerable when used in conjunction with Intel Virtualization Technology (VMX):
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
Intel processors that lack VMX support will not report VMX status:
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion
In some cases, which are believed to be rare, there may be no mitigation available due to the PTE inversion technique being incompatible with the number of physical address bits used by the processor and the amount of memory installed in the system. In these cases, the file will indicate the no mitigations are in place and that the system is vulnerable:
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Vulnerable
If you've modified the default behavior of L1 data cache flushes, the VMX status will indicate the change in behavior. If the selected mode is always, the file contents will be similar to the following (Hyper-Threading is disabled in the example but may be enabled on your system):
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled
If the selected mode is "never", the file contents will be similar to the following (Hyper-Threading is disabled in the example but may be enabled on your system):
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled
It is possible to check if your system is using the L1 data cache flush mechanism provided by updated microcode or if it is using the software fallback mechanism provided by the kernel. Cache flushes will be performed by the microcode when the "flush_l1d" feature is listed in the CPU flags field (your system may have a different set of CPU flags listed):
$ grep -m 1 flush_l1d /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
The software fallback mechanism will be in use if the "flush_l1d" flag is not present.
For more information on these issues, please see the following reference documents:
- 2018 Aug 14 at 17:00 UTC: the issue is made public