[PATCH 0/5] x86: CVE-2017-5715, aka Spectre

[Jeff Law]

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 <ebotcazou@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