On 07/24/2017 02:57 AM, Segher Boessenkool wrote:
>> Sadly, there's no way short of listing them and keeping that list
>> up-to-date over time by hand.  If we want to do that, I would suggest
>> we note the processors with full support as well as those with partial
>> support using the -fstack-check=specific prologues.
> 
> Oh, I thought everything got the partial support.  Targets that get _no_
> protection should just warn whenever someone asks for it, I think.
Almost everything gets support for probing the dynamic area (exceptions
would be ports that define their own expander for allocating dynamic
stack space).

We could probably set up a hook to query the backend WRT what, if any,
prologue support for either stack-clash protection, or
-fstack=check=specific protection they provide.

THe default hook would probably look something like


enum target_stack_clash_protection_status {
  /* Target provides no protection for stack clash attacks.  */
  NO_PROTECTION,

  /* Target provides partial protection in its prologue using
     -fstack-check=specific prologues.  */
  STACK_CHECK_PROTECTION,

  /* Target provides full protection in its prologue using
     custom prologue sequences for -fstack-clash-protection.   */
  FULL_STACK_CLASH_PROTECTION
}

enum target_stack_clash_protection_status
foo ()
{
  if (STACK_CHECK_STATIC_BUILTIN)
    return STACK_CHECK_PROTECTION
  return NO_PROTECTION
}


Note any target providing stack-clash protection via custom prologues
would have to override the default.  BUt that seems reasonable to me.


Given something like that, we could do something like

if (flag_stack_clash_protection)
  {
    if (foo () == NO_PROTECTION)
      warning ("Static stack allocations are not protected from
stack-clash.);
    else if (foo () == STACK_CHECK_PROTECTION)
      warning ("Static stack allocations are partially protected from
stack-clash");
    else if (foo () == FULL_STACK_CLASH_PROTECTION)
      ;
  }

We could so something similar for the dynamic area.  The default would
key off having a viable expander for allocate_stack.  If it does, then
it would default to unprotected dynamic allocations.  Targets such as
ppc would override the default as it has the expander, but the expander
knows how to deal with stack clash protection.

Jeff

Reply via email to