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.
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. Jeff