Re: RFC: stack/heap collision vulnerability and mitigation with GCC

[Eric Botcazou <ebotcazou@adacore.com>]

> In the patches Jeff is going to post, we have (at least for
> -fasynchronous-unwind-tables which is on by default on e.g. x86)
> precise unwind info even with the new stack check mode.
> ira.c currently has:
>        /* We need the frame pointer to catch stack overflow exceptions if
>           the stack pointer is moving (as for the alloca case just above). 
> */
>        || (STACK_CHECK_MOVING_SP
> 
>            && flag_stack_check
>            && flag_exceptions
>            && cfun->can_throw_non_call_exceptions)

There is the same test in ix86_finalize_stack_realign_flags.

> For alloca we have a frame pointer for other reasons, the question is
> if we really need this hunk even if we provided proper unwind info
> even for the Ada -fstack-check mode.  Or, if we provide proper unwind info
> for -fasynchronous-unwind-tables, if the above could not be also
> && !flag_asynchronous_unwind_tables.  Eric, what exactly is the reason
> for the above, is it just lack of proper CFI notes, or something different?

The reason was the assertion present in ix86_adjust_stack_and_probe that the 
CFA was not the stack pointer and which was removed in r230245:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01499.html
I agree that it's probably obsolete by now.

> Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
> while it is shorter, is it actually faster or as slow as movq $0, (%rsp)
> or movl $0, (%esp) ?

It's the idiom used on Windows since day #1, see libgcc/config/i386/cygwin.S.

-- 
Eric Botcazou