On Wed, Jan 10, 2018 at 2:52 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Wed, Jan 10, 2018 at 5:14 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote: >>> On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou <ebotca...@adacore.com> >>> wrote: >>> >> 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. >>> > >>> > I think that you're a bit optimistic here and that implementing a generic >>> > and >>> > robust framework at the RTL level might require some time. Given the >>> > time and >>> > (back-)portability constraints, it might be wiser to rush into >>> > architecture- >>> > specific countermeasures than to rush into an half-backed RTL framework. >>> >>> Let me also say that while it might be nice to commonize code introducing >>> these >>> mitigations as late as possible to not disrupt optimization is important. >>> So I >>> don't see a very strong motivation in trying very hard to make this more >>> middle-endish, apart from maybe sharing helper functions where possible. >> >> That and perhaps a common option to handle the cases that are common to >> multiple backends (i.e. move some options from -m* namespace to -f*). >> I'd say the decision about the options and ABI of what we emit is more >> important than where we actually emit it, we can easily change where we do >> that over time, but not the options nor the ABI. >> > > My x86 mitigations are specific to x86 processors. I don't know if > these options > are relevant to other processors. However, it is a good to have a common > option to enable mitigations, which can be built on top of processor specific > options. For example, -fmitigate-spectre may simply imply > > -mindirect-branch=thunk -mindirect-branch-register > > For kernel, they may want to use > > -mindirect-branch=thunk-extern -mindirect-branch-register > > instead.
Yes, that's a good idea (common -fFOO umbrella option mapping to target bits). And of course targets can follow x86 in their -mindirect-branch-foo flag namings (if semantic matches). Richard. > -- > H.J.
