top of page
White Structure

Experienced Technology Product Manager adept at steering success throughout the entire product lifecycle, from conceptualization to market delivery. Proficient in market analysis, strategic planning, and effective team leadership, utilizing data-driven approaches for ongoing enhancements.

  • Twitter
  • LinkedIn
White Structure
Writer's pictureArun Nukula

L1 Terminal Fault a.k.a L1TF

Updated: Apr 2, 2019


Intel has disclosed details on a new class of CPU speculative-execution vulnerabilities known collectively as “L1 Terminal Fault” that can occur on past and current Intel processors (from at least 2009 – 2018)

Like Meltdown, Rogue System Register Read, and "Lazy FP state restore", the “L1 Terminal Fault” vulnerability can occur when affected Intel microprocessors speculate beyond an unpermitted data access. By continuing the speculation in these cases, the affected Intel microprocessors expose a new side-channel for attack

Three CVEs collectively cover this form of vulnerability for Intel CPU's

  1. CVE-2018-3646

  2. CVE-2018-3620

  3. CVE-2018-3615

Let's discuss these CVE's one at a time

CVE-2018-3646

Vulnerability Summary

  • Referred as L1 Terminal Fault - VMM

  • It's one of these Intel microprocessor vulnerabilities and impacts hypervisors. It may allow a malicious VM running on a given CPU core to effectively infer contents of the hypervisor's or another VM's privileged information residing at the same time in the same core's L1 Data cache. Because current Intel processors share the physically-addressed L1 Data Cache across both logical processors of a Hyperthreading (HT) enabled core, indiscriminate simultaneous scheduling of software threads on both logical processors creates the potential for further information leakage

  • CVE-2018-2646 has two currently known attack vectors

  • Sequential-Context Attack

  • A malicious VM can potentially infer recently accessed L1 data of a previous context (hypervisor thread or other VM thread) on either logical processor of a processor core.

  • Concurrent-Context Attack

  • A malicious VM can potentially infer recently accessed L1 data of a concurrently executing context (hypervisor thread or other VM thread) on the other logical processor of the hyper-threading processor core

Mitigation Summary

  • Mitigation of Sequential-Context Attack vector is achieved by vSphere updates and patches.This mitigation is enabled by default and does not impose a significant performance impact

  • Mitigation of the Concurrent-Context Attack vector requires enablement of a new feature known as the ESXi Side-Channel-Aware Scheduler. The initial version of this feature will only schedule the hypervisor and VMs on one logical processor of an Intel Hyperthreading-enabled core. This feature may impose a non-trivial performance impact and is not enabled by default

Mitigation Process

Update Phase


The Sequential-context attack vector is mitigated by a vSphere update to the product versions listed in VMware Security Advisory VMSA-2018-0020.

This mitigation is dependent on Intel microcode updates (provided in separate ESXi patches for most Intel hardware platforms) which are also documented in VMSA-2018-0020.

IMPORTANT NOTE

As displayed in the workflow above, vCenter Server should be updated prior to applying ESXi patches. Notification messages were added in the aforementioned updates and patches to explain that the ESXi Side-Channel-Aware Scheduler must be enabled to mitigate the Concurrent-context attack vector of CVE-2018-3646. If ESXi is updated prior to vCenter you may receive cryptic notification messages relating to this. After vCenter has been updated, the notifications will be shown correctly.

Planning Phase

The Concurrent-context attack vector is mitigated through enablement of the ESXi Side-Channel-Aware Scheduler which is included in the updates and patches listed in VMSA-2018-0020. This scheduler is not enabled by default. Enablement of this scheduler may impose a non-trivial performance impact on applications running in a vSphere environment. The goal of the Planning Phase is to understand if your current environment has sufficient CPU capacity to enable the scheduler without operational impact.

The following list summarizes potential problem areas after enabling the ESXi Side-Channel-Aware Scheduler:

  • VMs configured with vCPUs greater than the physical cores available on the ESXi host

  • VMs configured with custom affinity or NUMA settings

  • VMs with latency-sensitive configuration

  • ESXi hosts with Average CPU Usage greater than 70%

  • Hosts with custom CPU resource management options enabled

  • HA Clusters where a rolling upgrade will increase Average CPU Usage above 100%

IMPORTANT NOTE

The above list is meant to be a brief overview of potential problem areas related to enablement of the ESXi Side-Channel-Aware Scheduler. The VMware Performance Team has provided an in-depth guide as well as performance data in KB 55767. It is strongly suggested to thoroughly review this document prior to enablement of the scheduler.

It may be necessary to acquire additional hardware, or rebalance existing workloads, before enablement of the ESXi Side-Channel-Aware Scheduler. Organizations can choose not to enable the ESXi Side-Channel-Aware Scheduler after performing a risk assessment and accepting the risk posed by the Concurrent-context attack vector. This is NOT RECOMMENDED and VMware cannot make this decision on behalf of an organization.

Scheduler Enablement Phase

After addressing the potential problem areas described above during the Planning Phase, the ESXi Side-Channel-Aware Scheduler must be enabled to mitigate the Concurrent-context attack vector of CVE-2018-3646. The scheduler can be enabled on an individual ESXi host via the advanced configuration option hyperthreadingMitigation. This can be done by performing the following steps:

Enabling the ESXi Side-Channel-Aware Scheduler using the vSphere Web Client or vSphere Client

  1. Connect to the vCenter Server using either the vSphere Web or vSphere Client.

  2. Select an ESXi host in the inventory.

  3. Click the Manage (5.5/6.0) or Configure (6.5/6.7) tab.

  4. Click the Settings sub-tab.

  5. Under the System heading, click Advanced System Settings.

  6. Click in the Filter box and search VMkernel.Boot.hyperthreadingMitigation

  7. Select the setting by name and click the Edit pencil icon.

  8. Change the configuration option to true (default: false).

  9. Click OK.

  10. Reboot the ESXi host for the configuration change to go into effect.

Enabling the ESXi Side-Channel-Aware Scheduler using ESXi Embedded Host Client

  1. Connect to the ESXi host by opening a web browser to https://HOSTNAME.

  2. Click the Manage tab

  3. Click the Advanced settings sub-tab

  4. Click in the Filter box and search VMkernel.Boot.hyperthreadingMitigation

  5. Select the setting by name and click the Edit pencil icon

  6. Change the configuration option to true (default: false)

  7. Click Save.

  8. Reboot the ESXi host for the configuration change to go into effect.

Enable ESXi Side-Channel-Aware Scheduler setting using ESXCLI

  1. SSH to an ESXi host or open a console where the remote ESXCLI is installed. For more information, see the http://www.vmware.com/support/developer/vcli/.

  2. Check the current runtime value of the HTAware Mitigation Setting by running

  3. esxcli system settings kernel list -o hyperthreadingMitigation

  4. To enable HT Aware Mitigation , run this command

  5. esxcli system settings kernel set -s hyperthreadingMitigation -v TRUE

  6. Reboot the ESXi host for the configuration change to go into effect.

Refer to the following KB articles for product-specific mitigation procedures and/or vulnerability analysis:

CVE-2018-3620

  • Referred as L1 Terminal Fault - OS ( Operating System-Specific Mitigations )

  • VMware has investigated the impact CVE-2018-3620 may have on virtual appliances. Details on this investigation including a list of unaffected virtual appliances can be found in KB 55807.

  • Products that ship as an installable windows or linux binary are not directly affected, but patches may be required from the respective operating system vendor that these products are installed on. VMware recommends contacting your 3rd party operating system vendor to determine appropriate actions for mitigation of CVE-2018-3620. This issue may be applicable to customer-controlled environments running in a VMware SaaS offering, review KB 55808.

CVE-2018-3615

  • Referred as L1 Terminal Fault - SGX

  • CVE-2018-3615 does not affect VMware products or services. See KB 54913 for more information


167 views0 comments

Recent Posts

See All
bottom of page