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