On Thu, Jan 11, 2018 at 2:16 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law <l...@redhat.com> wrote: >> On 01/10/2018 06:14 AM, Jakub Jelinek 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. >> From a UI standpoint, I think the decision has already been made as LLVM >> has already thrown -mretpolines into their tree. Sigh. > > Well, given retpolines are largely kernel relevant right now we don't > need to care here. > >> So I think the one thing we ought to seriously consider is at least >> reserving -mretpoline for this style of mitigation of spectre v2. ALl >> target's don't have to implementation this style mitigation, but if they >> do, they use -mretpoline. > > And I'd also like people not to bikeshed too much on this given we're > in the situation > of having exploitable kernels around for which we need a cooperating > compiler. So > during the time we bikeshed this (rather than reviewing the actual > patches) we have > to "backport" the current non-upstream state anyway to deliver fixed > kernels to our > customer. > > Yes, if this were a "normal feature" we could continue discussing and > trying to design > sth nice and shiny. But this isn't a normal feature. > > So please - I'd also like to get this into a released compiler (aka > 7.3) as soon as possible > (given a RC for 7.3 was scheduled to be early this week).
Hi Uros, Can you take a look at my x86 backend changes so that they are ready to check in once we have consensus. Thanks. -- H.J.
