On Tue, Jan 9, 2018 at 10:52 AM, Jeff Law <l...@redhat.com> wrote: > 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.
Doing this at RTL expansion time may not work well with RTL optimizing paases nor IRA/LRA. We may wind up undoing all kinds of optimizations as well code sequences. -- H.J.
