On 01/11/2018 03:16 AM, Richard Biener 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. That's still TBD as far as I can tell. I certainly hope we don't have to go retpolines in user space, at least not in the general case. I'm holding out hope that the kernel folks are going to save the day.
> >> 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. Believe me, after dealing with stack clash, I'm fully aware of the constraints folks dealling with mitigation are under. Jeff
