Systems engineers at Google have come up with a technique to strengthen applications against a recently revealed attack called Spectre that could abuse a CPU feature to steal passwords, keys and other secrets from a program’s memory.
The Spectre attack, which so far has two known variants takes advantage of a CPU optimization feature called speculative execution. Modern processors use this to guess the execution path a program’s code will take when faced with a conditional branch and execute instructions down that branch in advance.
In cases where the CPU’s “speculation” proves correct, it increases performance because the execution results can be made available to programs instantly. However, it also creates a security risk if information about the speculative execution can be determined through a side-channel such as cache timings.
This week, researchers unveiled two such attacks: Meltdown and Spectre. Meltdown is more serious because it can expose kernel memory to userspace programs. However, it mostly affects Intel CPUs and can be patched more easily through OS changes that better isolate the kernel memory space.
Spectre affects processors from all vendors, but is harder to exploit. It can, at the very least, be used to trick applications to expose their own secrets by forcing the CPU to speculatively execute certain branches. This is known as branch target injection.
Since Spectre exploitation does not involve the kernel, the Kernel Page Table Isolation (KPTI) that is being implemented in operating systems to mitigate Meltdown has no bearing on this attack.
Mitigating Spectre will require CPU microcode updates, but even those will likely be stop-gap solutions because the attack possibilities are not yet fully understood and researchers will almost certainly come up with new exploitation techniques for it. As the researchers who found Spectre said: “It will haunt us for quite some time.”
In the meantime, application developers can take measures to protect their own programs through a binary modifcation technique that relies on what Google calls “retpoline sequences.”
“Retpoline sequences are a software construct which allow indirect branches to be isolated from speculative execution,” Paul Turner, a senior staff engineer for technical infrastructure at Google, said in a technical write-up. “This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches.”
“The name ‘retpoline’ is a portmanteau of ‘return’ and ‘trampoline,” Turner said. “It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will ‘bounce’ endlessly.”
In more simple terms, the binary itself will force the CPU’s speculative execution down a path where it will be stuck, preventing attempts of using it to attack the binary. It’s essentially setting traps for indirect branches to avoid their speculative execution.
Google said it has shared Retpoline with its industry partners and has deployed it on its own systems with “negligible impact on performance.” Support for the technique is being added to the LLVM and GCC compilers, as well as to the Linux kernel.
“With some effort we have the average overall overhead within the 0-1.5% range for our internal workloads, including some particularly high packet processing engines,” Turner said in a post on the Linux kernel mailing list.
KPTI, the mitigation for Meltdown, is also expected to impact performance, but Google’s real-world tests showed that the initial estimates—as much as 30 percent—were greatly exaggerated. So, if you’re delaying the kernel patches out of concern for performance, you should do your own tests.
“In our own testing, we have found that microbenchmarks can show an exaggerated impact,” the company said in a blog post. “On most of our workloads, including our cloud infrastructure, we see negligible impact on performance.”