CVE-2018-3693: Spectre v1 subvariant - Speculative Bounds Check Bypass Store[BCBS]

Root Cause

Speculative Execution: Bounds Check Bypass Store

Modern processors employ numerous techniques to improve system performance. One such technique is Speculative Execution. As the name suggests, in order to improve performance, the processor speculates about the future execution flow of a program (the Linux kernel can be thought of as a special kind of program for this purpose), running potential program instructions along the speculative path until it is confirmed whether the speculated path was correct, or incorrect. In the case that the speculated path was correct, a performance improvement is obtained. In the case that the speculated path was incorrect, any results obtained from the speculation must carefully be unwound to return the microprocessor to the correct path in such a way as to ordinarily be undetectable.

Consider an example:

char flag;
char cmd[BUFFER_LENGTH]
<snip>
if (pos >= BUFFER_LENGTH)
    return -1;
cmd[pos++] = tok;
    If (flag == ‘R’)
        read_cmd(cmd)
    else
        write_cmd(cmd)

In the above example, while the processor is waiting (for example for a slow load to complete from DDR memory) to confirm if pos exceeds the buffer length or not, it could speculatively execute the instruction which updates the cmd buffer. Thus bypassing the bounds check. If user could control the value of the pos variable, they may be able to speculatively overflow the cmd buffer in such a way as to affect subsequent speculative operations.

Speculatively executed instructions are not normally visible to the user or programmer (they are not committed to the architectural program state). When the processor eventually resolves the value of pos and the bounds check fails, the processor rolls back all speculatively executed instructions and resumes execution after the bounds check along the correct path as if the speculation had never occurred.

However before such a roll back, speculatively executed subsequent instructions would use the change made by the cmd[pos++] = tok operation. If pos is out of bounds, it will overwrite beyond cmd[] buffer, possibly also overwriting nearby data in memory such as the flag variable. This would, in turn, decide the course of the speculative execution and further changes to the cache memory, which can be observed by a malicious user via targeted cache side-channel attack or analysis methods.

Impact

The Speculative Bounds Check Bypass Store variant could be used to influence the course of the speculative execution by targeting local automatic variables or function pointers and/or return addresses found in the memory. It might be used to direct the processor’s speculative engine to different code paths, the effects of which are observed by an attack via side channels to know memory contents. This can then be leveraged to access secret information and/or build another attack.

Mitigation

There is no known workaround. All Red Hat customers should deploy the updated kernel as soon as it’s available.

Customers are advised to take a risk-based approach in mitigating this issue. Systems that require high degrees of security and trust should be addressed first, and should be isolated from untrusted systems until such time as treatments can be applied to those systems to reduce the risk of exploit.

Within the Red Hat Linux kernel we will be using the following recommended mitigation for Speculative Bounds Check Bypass to ensure that speculative execution does not occur past the bounds check instructions. This can be achieved by introducing serializing instructions like ‘lfence’ after the bounds check instructions and before the following instructions.

if (pos >= BUFFER_LENGTH)
    return -1;
asm volatile (“lfence”:::”memory”);
cmd[pos++] = tok

Alternatively, speculative execution may be controlled by constraining the array index. For example, in the kernel, the array_index_nospec() macro can be used:

if (pos >= BUFFER_LENGTH)
    return -1;
pos = array_index_nospec(pos, BUFFER_LENGTH);
cmd[pos++] = tok

This macro ensures that the returned array index is always within the array bounds and that speculative execution cannot access beyond the bounds of the array. A similar approach can be used in user space. For more details about potential mitigations, see the Intel whitepaper Analyzing potential bounds check bypass vulnerabilities.