Third, those requests have to trigger a potentially vulnerable code fragment to speculate into attacker-selected behavior.

Second, the attacker must be able to make some kind of HTTP or RPC requests to the victim Go program. These mitigations would only be necessary when there is a potential Spectre attack against a Go program, which would require all of the following to be true.įirst, an attacker must be able to run arbitrary code on the same CPUs as a victim Go program containing a secret. They are included in the Go toolchain as a kind of “defense in depth” for users with very special use cases (or significant paranoia). ApplicabilityĪt time of writing, we do not use either of these mitigations for Go programs running at Google, nor do we anticipate doing so. This change typically slows down execution by around 10-15% again, the exact slowdown depends on the workload. This mitigation replaces every indirect call instructions with use of a retpoline gadget. The ret mitigation can be enabled in both the compiler and the assembler and changes code generation to emit protections against Spectre variant 2 (“branch target injection”). This change typically slows down execution by around 5-10% the exact slowdown depends on the workload. The mitigation ensures that the CPU does not access arbitrary memory, by masking the index to zero when speculating incorrectly.

The index mitigation can be enabled in the compiler and changes code generation to emit protections against Spectre variant 1 (“bounds check bypass”). The special case -spectre=all enables all available mitigations. The compiler and assembler both have a new flag -spectre that is given a list of Spectre mitigations to enable, as in -spectre=index or -spectre=index,ret. Go 1.15 adds support for enabling code generation adjustments to mitigate the effect of two variants of the Spectre family of CPU vulnerabilities.

Spectre logo changes