Protecting against the new “L1TF” speculative vulnerabilities

Earlier this year, Google's Project Zero team disclosed serious security flaws rooted in “speculative execution,” a technique used by many modern processors to optimize performance. “Spectre” and “Meltdown” were the first instances of these attacks, which exploited out-of-order execution. Google’s engineering teams have been working to protect our customers and systems from these classes of attacks across the entire suite of our products, including Google Cloud Platform (GCP), G Suite, and the Google Chrome and Chrome OS products. We also continue to collaborate with hardware and software vendors across the industry to help protect all users and the broader web.

Today, Intel published details on a new set of speculative execution vulnerabilities titled “L1 Terminal Fault (L1TF),” affecting selected Intel products. These have been assigned CVE-2018-3615 (for SGX), CVE-2018-3620 (for operating systems and SMM) and CVE-2018-3646 (for virtualization).

Directly exploiting these vulnerabilities requires control of hardware resources that are accessible only with operating system level control of the underlying physical or virtual processors. Unpatched operating systems may also permit indirect exploitation, dependent on their handling of operations that manipulate memory mappings.

We have deployed mitigations to Google’s infrastructure, including the infrastructure that underpins Google Cloud, which prevent the creation of vulnerable page-table entries within our host OS. In this blog, we’ll go into detail about these vulnerabilities, how we mitigate guest-controlled entries not controlled by the host OS, and what steps customers may need to take to ensure they are fully protected.

Understanding L1TF

Unlike previous attacks, the new L1TF variants exploit speculative execution by attacking the configuration of processor-level data structures rather than a program’s control flow. Here, “L1” refers to the Level-1 Data cache (L1D), a small on-core resource used to accelerate memory access.

The contents of this cache (known as cache lines) can potentially be speculatively examined during the resolution of a malformed or not-present page-fault. Further, during speculative evaluation accompanying the fault, it is possible to bypass the usual protections that ensure that a cache line may only be read by the address space (e.g., process or virtual machine) that loaded it. Therefore, an L1TF attack means that private data fragments loaded in the L1 cache can potentially be read by a different process or VM that shares access to the cache.

Defending against this method of attack is particularly challenging for virtualized environments, as a virtual machine exposes the state necessary to construct an attack. Specifically, an attacker could intentionally configure their own page tables to direct these faults and probe the cache of the core on which they are currently executing. The notion of a “core” here is important as it encompasses the processing units (logical CPUs, commonly also referred to as “hyperthread siblings”) that share an L1 data cache. Important to note is that the attack affects only the local L1 cache, and it is not possible to extract data from the L1 cache of another core.

Google Cloud mitigations against L1TF

Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines. This isolation also ensures that, in the case that different virtual machines are scheduled sequentially, the L1 data cache is completely flushed to ensure that no vulnerable state remains. In addition, we have also developed and deployed infrastructure that allows us to monitor our hosts for certain classes of these attacks.

How to protect your environment against L1TF

The mitigations described above address the L1TF vulnerability for the majority of Google Cloud customers.

Customers are encouraged to update their images to prevent the possibility of indirect exploitation within their environments.  This is particularly important for customers running their own multi-tenant services. For product-specific details and recommended user actions, please refer to the Product Status page.

New and emerging security vulnerabilities will always be a reality, and Google constantly works across the industry to discover and address vulnerabilities to protect our users and customers. Google Cloud customers benefit from the shared responsibility model of public clouds, meaning much of the burden of addressing new vulnerabilities is offloaded to their cloud provider. For more information about our multi-layered security approach, download our Infrastructure Security Design whitepaper.