| Disclosure date: 2018-01-03 Published date: 2018-01-03 |
 Severity rating: 5.6 Medium |
Industry-wide severity ratings can be found in the National Vulnerability Database |
Aliases
- Spectre variant 2
Overview
Branch target injection takes advantage of the indirect branch predictors used by processors to direct what operations are speculatively executed after a near indirect branch instruction. By controlling how indirect branch predictors operate (“training”), an attacker can cause certain instructions to be speculatively executed and then use the effects the malicious code has on the processor’s caches to infer data values.
For conditional direct branches, there are only two options as to what code speculatively executes: the target of the branch or the fall-through path of instructions directly subsequent to the branch. An attacker cannot cause code to be speculatively executed outside of those locations. Indirect branches, however, can cause speculative execution1 of code at a wider set of targets. Branch target injection works by causing an indirect branch to speculatively execute a ‘gadget’ which creates a side channel based on sensitive data available to the victim.
Processors use indirect branch predictors to control only the operation of the branch instructions outlined below:
| Branch Type | Instruction | Opcode |
|---|---|---|
| Near Call Indirect | CALL r/m16, CALL r/m32, CALL r/m64 | FF /2 |
| Near Jump Indirect | JMP r/m16, JMP r/m32, JMP r/m64 | FF /4 |
| Near Return | RET, RET Imm16 | C3, C2 Iw |
References below to indirect branches are only to near call indirect, near jump indirect and near return instructions.
The ability of a malicious actor to interfere with the processor’s indirect branch predictors to cause such a side channel is highly dependent on the processor’s microarchitectural implementation, and the exact methods used to do so may vary across processors. For example, the indirect branch predictors in some processor implementations may only use a subset of the overall address to index into the predictor. If an attacker can discern what subset of bits are used, the attacker can use this information to create interference due to aliasing. Similarly, on processors that support Intel® Hyper-Threading Technology (Intel® HT Technology), whether one thread’s behavior can influence the prediction of the other thread is a consideration. The branch target injection method can only occur for a near indirect branch instruction.
Mitigation
Two mitigation techniques have been developed for branch target injection: indirect branch control mechanisms and a software approach called “return trampoline,” also known as retpoline. This allows a software ecosystem to select the approach that works for particular security, performance and compatibility goals.
Indirect branch control mechanisms introduce an interface between the processor and system software that allows system software to prevent an attacker from controlling indirect branch predictions, such as by invalidating indirect branch predictors at appropriate times. Details of this interface will be provided in a future revision of the Intel® 64 and IA-32 Architectures Software Developer’s Manuals. For many existing processors, this mitigation requires updated system software and a microcode update to support the new interface. This interface will have built-in support on future Intel® processors.
This new interface supports three new indirect branch control mechanisms:
- Indirect Branch Restricted Speculation (IBRS): Restricts speculation of indirect branches.
- Single Thread Indirect Branch Predictors (STIBP): Prevents indirect branch predictions from being controlled by the sibling Hyperthread.
- Indirect Branch Predictor Barrier (IBPB): Prevents indirect branch predictions after the barrier from being controlled by software executed before the barrier.
Appropriately written software can use these mechanisms to defend against branch target injection attacks.These mechanisms are available on existing processors with updated microcode. Future processors will include this interface built-in, and may improve the performance of these mechanisms.
The second technique introduces the concept of a “return trampoline”, also known as retpoline. Essentially, software replaces indirect near jump and call instructions with a code sequence that includes a direct call to seed the return predictor with a safe target, a store of the target of the branch in question onto the stack and then a return (RET) instruction to jump to that location. The prediction of this replacement return is effectively constrained using this method. This technique may perform better than the first technique for certain workloads on many current Intel processors.
Intel has worked with various open source compilers to add support for retpoline, and with the OS vendors to use these techniques where appropriate. For Intel® Core™ processors of the Broadwell generation and later, this retpoline mitigation strategy also requires a microcode update to be applied for the mitigation to be most effective.
Full details of retpoline are described in Retpoline: A Branch Target Injection Mitigation.
Applications
Since most indirect branches are generated by compilers when building a binary, deploying retpoline requires recompiling the software that needs mitigation. A retpoline-capable compiler can avoid generating any vulnerable indirect CALL or indirect JMP instructions and instead uses retpoline sequences. Of course, for code not generated by the compiler (such as inline assembly) programmers must insert retpoline sequences manually.
Front-end Web Developers
Front-end web developers should use the indirect branch control mechanisms described in the Mitigations section above. Follow the recommendations for Applications to insert retpoline sequences where needed.
Runtime Developers
The managed runtime JIT and AOT compilers may generate indirect branches. Therefore when the managed runtime is used in sandbox environments or where isolation is required, for microprocessors listed in the security advisory, the managed runtime JIT and AOT compilers can automatically generate retpoline sequences for “near call indirect” and “near jump indirect” instead of vulnerable indirect branches.
Managed runtimes could be used in a virtualized environment. A valuable tool in modern data centers is live migration of virtual machines (VMs) among a cluster of bare-metal hosts. However, those bare-metal hosts often differ in hardware capabilities. These differences could prevent a VM that started on one host from being migrated to another host that has different capabilities. For instance, a VM using Intel® Advanced Vector Extensions 512 (Intel® AVX-512) instructions could not be live-migrated to an older system without Intel® AVX-512.
A common approach to solving this issue is exposing the oldest processor model with the smallest subset of hardware features to the VM. This addresses the live-migration issue, but results in a new issue: Software using model/family numbers from CPUID can no longer detect when it is running on a newer processor that is vulnerable to exploits of Empty RSB conditions.
To remedy this situation, a managed runtime running in a virtualized environment needs to query bit 2 of the IA32_ARCH_CAPABILITIES MSR, known as “RSB Alternate” (RSBA). Since applications can’t read MSRs directly, OS vendors may expose this information through an API to help applications take corrective measures. When RSBA is set, it indicates that the underlying VM may run on a processor vulnerable to exploits of Empty RSB conditions regardless of the processor’s Family/Model signature, and that the managed runtime should deploy appropriate mitigations.
OS and Driver Developers
Linux*
The Linux kernel implements retpoline to protect the kernel from exploits. The CONFIG_RETPOLINE build option is used to enable support. You can check for support on many distributions by running the following command:
grep CONFIG_RETPOLINE /boot/config-`uname -r`
This build option indicates whether retpoline support was requested in the build. However, even with this option set, you can successfully build the kernel even if the compiler does not support retpoline. In this case, the kernel will only contain minimal mitigations with retpoline in assembly code. These kernels will indicate that they are still “Vulnerable” to branch target injection (Spectre variant 2), as shown below:
# cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Vulnerable: Minimal generic ASM retpoline
Kernels that were built with a compiler that does support retpoline will indicate that they are mitigated and are no longer vulnerable:
# cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline
Virtual Machine Monitor Developers
In a processor supporting Intel® Hyper-Threading Technology, a core (or physical processor) may include multiple logical processors. In such a processor, the logical processors sharing a core may share indirect branch predictors. As a result of this sharing, software on one of a core’s logical processors may be able to control the predicted target of an indirect branch executed on another logical processor of the same core.
This sharing occurs only within a core. Software executing on a logical processor of one core cannot control the predicted target of an indirect branch by a logical processor of a different core.
A valuable tool in modern data centers is live migration of virtual machines (VMs) among a cluster of bare-metal hosts. However, those bare-metal hosts often differ in hardware capabilities. These differences could prevent a virtual machine that started on one host from being migrated to another host that has with different capabilities. For instance, a virtual machine using Intel® Advanced Vector Extensions 512 (Intel® AVX-512) instructions could not be live-migrated to an older system without Intel® AVX-512.
A common approach to solving this issue is exposing the oldest processor model with the smallest subset of hardware features to the VM. This addresses the live-migration issue, but results in a new issue: Software using model/family numbers from CPUID can no longer detect when it is running on a newer processor that is vulnerable to exploits of Empty RSB conditions.
To remedy this situation, an operating system running as a VM can query bit 2 of the IA32_ARCH_CAPABILITIES MSR, known as “RSB Alternate” (RSBA). When RSBA is set, it indicates that the VM may run on a processor vulnerable to exploits of Empty RSB conditions regardless of the processor’s DisplayFamily/DisplayModel signature and that the operating system should deploy appropriate mitigations. Virtual machine managers (VMM) may set RSBA via MSR interception to indicate that a virtual machine might run at some time in the future on a vulnerable processor.
Developers of Software Running in an Enclave
IBRS can be used to mitigate branch target injection within protected enclaves on supported processors. Processors that support IBRS enumerate CPUID.(EAX=7H,ECX=0):EDX[26] as 1, and these processors provide the following guarantees without any enabling by software:
- The predicted targets of near indirect branches executed in an enclave (a protected container defined by Intel® Software Guard Extensions (Intel® SGX)) cannot be controlled by software executing outside the enclave.
- If the default treatment of SMIs and SMM is active, software executed before a system-management interrupt (SMI) cannot control the predicted targets of indirect branches executed in system-management mode (SMM) after the SMI.
System Administrators
Retpoline is known to be an effective branch target injection mitigation on Intel processors belonging to family 6 (enumerated by the CPUID instruction) that do not have support for enhanced IBRS. On processors that support enhanced IBRS, enhanced IBRS should be used for mitigation instead of retpoline.
Empty Return Stack Buffer Mitigation on Skylake-generation
The Return Stack Buffer (RSB) is a fixed-size stack implemented in hardware. As with any stack, it can underflow in certain conditions causing undesirable behavior. “RSB stuffing” is a technique to reduce the likelihood of an underflow from occurring.
The predictable speculative behavior of the RET instruction is the key to retpoline being a robust mitigation. RET has this behavior on all processors which are based on the Intel® microarchitecture codename Broadwell and earlier when updated with the latest microcode. Processors based on the Intel® microarchitecture codename Skylake and its close derivatives have different behavior than other processors when the RSB is empty. Processors with this RSB behavior can be identified using the DisplayFamily/DisplayModel signatures provided by the CPUID instruction. For further details, refer to Retpoline: A Branch Target Injection Mitigation.
References
- Introduction to Speculative Execution Side Channel Methods
- Retpoline: A Branch Target Injection Mitigation
- Google* description of retpoline
- Intel® 64 and IA-32 Architectures Software Developer’s Manuals
- Related Intel Security Features and Technologies
Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources