Google Engineer Uncovers Holes In Linux's Speculative Execution Mitigations

There are some urgent fixes pending for the x86/x86_64 speculative execution handling for the Linux kernel following a Google security engineer discovering these issues, including one of the fixes address a situation that unfairly impacted AMD CPUs.

Queued up this morning in x86/urgent are a number of fixes to the Linux kernel's speculative execution mitigations.

First up is an issue over force disabling IBPB based on STIBP and enhanced IBRS. This incorrect handling of the Indirect Branch Prediction Barrier (IBPB) in some conditions could impact AMD CPUs against AMD's recommendations and also lead to applications being silently vulnerable to Spectre Variant Two attacks. Anthony Steinhauser of Google who uncovered these issues explained, "When STIBP is unavailable or enhanced IBRS is available, Linux force-disables the IBPB mitigation of Spectre-BTB even when simultaneous multithreading is disabled. While attempts to enable IBPB using prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent) which are used e.g. by Chromium or OpenSSH succeed with no errors but the application remains silently vulnerable to cross-process Spectre v2 attacks (classical BTB poisoning). At the same time the SYSFS reporting displays that IBPB is conditionally enabled when in fact it is unconditionally disabled. STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is unavailable, it makes no sense to force-disable also IBPB, because IBPB protects against cross-process Spectre-BTB attacks regardless of the SMT state. At the same time since missing STIBP was only observed on AMD CPUs, AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice."

Steinhauser also added, "enhanced IBRS is designed to protect cross-core BTB poisoning and BTB-poisoning attacks from user space against kernel (and BTB-poisoning attacks from guest against hypervisor), it is not designed to prevent cross-process (or cross-VM) BTB poisoning between processes (or VMs) running on the same core. Therefore, even with enhanced IBRS it is necessary to flush the BTB during context-switches, so there is no reason to force disable IBPB when enhanced IBRS is available."

So that first fix is enabling the Indirect Branch Prediction Barrier control even when Single Threaded Indirect Branch Predictors are unavailable or enhanced Indirect Branch Restricted Speculation is available.

A second issue uncovered and now with a patch pending is rogue cross-process Speculative Store Bypass Disable (SSBD) shutdown. This issue is about an optimization in the SSBD mitigation gone awry. The optimization is trying to avoid an expensive MSR write but has been deemed buggy and could allow an attacker to shutdown SSBD protection of a victim process and thereby expose Spectre Variant Four. "It is exploitable if the attacker creates a process which enforces SSBD and has the contrary value of STIBP than the victim process (i.e. if the victim process enforces STIBP, the attacker process must not enforce it; if the victim process does not enforce STIBP, the attacker process must enforce it) and schedule it on the same core as the victim process. If the victim runs after the attacker the victim becomes vulnerable to Spectre V4."

Rounding out this batch of x86/x86_64 speculation Linux bugs today is an issue where it is possible to enable indirect branch speculation even after it was force-disabled. Making matters worse, the prctl speculation control command could then report that it was force disabled even when indirect branch speculation is enabled. "Currently, it is possible to enable indirect branch speculation even after it was force-disabled using the PR_SPEC_FORCE_DISABLE option. Moreover, the PR_GET_SPECULATION_CTRL command gives afterwards an incorrect result (force-disabled when it is in fact enabled). This also is inconsistent vs. STIBP and the documentation which clearly states that PR_SPEC_FORCE_DISABLE cannot be undone. Fix this by actually enforcing force-disabled indirect branch speculation."

These three Linux speculation fixes are queued this morning in x86/urgent. They should be mainlined shortly and back-ported to all supported stable series for these rather significant holes in the current speculative execution handling by the Linux kernel. It's also the second Tuesday of the month so we will see if any other new vulnerability disclosures are made today.