On 01/07/2018 05:29 PM, H.J. Lu wrote: > On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law <l...@redhat.com> wrote: >> On 01/07/2018 03:58 PM, H.J. Lu wrote: >>> This set of patches for GCC 8 mitigates variant #2 of the speculative >>> execution >>> vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. >>> They >>> convert indirect branches to call and return thunks to avoid speculative >>> execution >>> via indirect call and jmp. >>> >>> >>> H.J. Lu (5): >>> x86: Add -mindirect-branch= >>> x86: Add -mindirect-branch-loop= >>> x86: Add -mfunction-return= >>> x86: Add -mindirect-branch-register >>> x86: Add 'V' register operand modifier >>> >>> gcc/config/i386/constraints.md | 12 +- >>> gcc/config/i386/i386-opts.h | 14 + >>> gcc/config/i386/i386-protos.h | 2 + >>> gcc/config/i386/i386.c | 655 >>> ++++++++++++++++++++- >>> gcc/config/i386/i386.h | 10 + >>> gcc/config/i386/i386.md | 51 +- >>> gcc/config/i386/i386.opt | 45 ++ >>> gcc/config/i386/predicates.md | 21 +- >>> gcc/doc/extend.texi | 22 + >>> gcc/doc/invoke.texi | 37 +- >> My fundamental problem with this patchkit is that it is 100% x86/x86_64 >> specific. >> >> ISTM we want a target independent mechanism (ie, new standard patterns, >> options, etc) then an x86/x86_64 implementation using that target >> independent framework (ie, the actual implementation of those new >> standard patterns). >> > > My patch set is implemented with some constraints: > > 1. They need to be backportable to GCC 7/6/5/4.x. > 2. They should work with all compiler optimizations. > 3. They need to generate code sequences are x86 specific, which can't be > changed in any shape or form. And the generated codes are quite opposite > to what a good optimizing compiler should generate. > > Given that these conditions, I kept existing indirect call, jump and > return patterns. > I generated different code sequences for these patterns during the final pass > when generating assembly codes. > > I guess that I could add a late target independent RTL pass to convert > indirect call, jump and return patterns to something else. But I am not sure > if that is what you are looking for. I don't see how those constraints are incompatible with doing most of this work at a higher level in the compiler. You just surround the resulting RTL bits with appropriate barriers to prevent them from getting mucked up by the optimizers. Actually I think you're going to need one barrier in the middle of the sequence to keep bbro at bay within the sequence as a whole.
It's really just a couple of new primitives to emit a jump as a call and one to slam in a new return address. Given those I think you can do the entire implementation as RTL at expansion time and you've got a damn good shot at protecting most architectures from these kinds of attacks. jeff
