Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Andreas Schwab]

On Sep 19 2017, Jeff Law  wrote:

> I know some early bits had hardcoded "8" in some places, but I didn't
> think those had ever been posted -- I may have given them to Matz for
> him to play with.  Are you using those perhaps?

Yes, that looks like what's been happening.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 09/19/2017 03:08 AM, Andreas Schwab wrote:
> On Sep 18 2017, Jeff Law  wrote:
> 
>> On 09/18/2017 10:09 AM, Andreas Schwab wrote:
>>> On Sep 18 2017, Jeff Law  wrote:
>>>
 Can you confirm if the probe was in the red zone vs the live areas on
 the stack?
>>>
>>> It overwrites a nearby variable.  sp + 8 happens to be the address of
>>> file_entries_new_size.
>>>
>>>0x000140e8 <+1172>:  mov r6, sp
>>>0x000140ec <+1176>:  add r3, r3, #7
>>>0x000140f0 <+1180>:  bic r3, r3, #7
>>>0x000140f4 <+1184>:  cmp r3, #4096   ; 0x1000
>>>0x000140f8 <+1188>:  bcc 0x14110 
>>>0x000140fc <+1192>:  sub r3, r3, #4096   ; 0x1000
>>>0x00014100 <+1196>:  sub sp, sp, #4096   ; 0x1000
>>>0x00014104 <+1200>:  cmp r3, #4096   ; 0x1000
>>>0x00014108 <+1204>:  str r0, [sp, #8]
>>>0x0001410c <+1208>:  bcs 0x140fc 
>>>0x00014110 <+1212>:  ldr r7, [r11, #-56] ; 0xffc8
>>>0x00014114 <+1216>:  sub sp, sp, r3
>>>0x00014118 <+1220>:  mov r1, #0
>>>0x0001411c <+1224>:  add r3, sp, #8
>>>0x00014120 <+1228>:  mov r0, r3
>>> => 0x00014124 <+1232>:  str r0, [sp, #8]
>>>
>>> Andreas.
>>>
>> Or better yet, include your .i and .s files in their entirety and the
>> gcc -v output
> 
> This was generated with a very simple and incomplete backport of
> -fstack-clash-protection to gcc7.  What I get with your full patches
> with gcc8 looks correct.
Ah.  FWIW, it looks almost as if you've got a sign wrong when probing
the residual alloca allocation.  THe "8" is also strange as I'd expect
it to be "4" since words are 4 bytes on ARM.

I know some early bits had hardcoded "8" in some places, but I didn't
think those had ever been posted -- I may have given them to Matz for
him to play with.  Are you using those perhaps?

I expect to have a backport to gcc-7 now that things are unblocking on
the trunk.  You'd be welcome to work from those.  It might save you some
headaches.

jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Andreas Schwab]

On Sep 18 2017, Jeff Law  wrote:

> On 09/18/2017 10:09 AM, Andreas Schwab wrote:
>> On Sep 18 2017, Jeff Law  wrote:
>> 
>>> Can you confirm if the probe was in the red zone vs the live areas on
>>> the stack?
>> 
>> It overwrites a nearby variable.  sp + 8 happens to be the address of
>> file_entries_new_size.
>> 
>>0x000140e8 <+1172>:  mov r6, sp
>>0x000140ec <+1176>:  add r3, r3, #7
>>0x000140f0 <+1180>:  bic r3, r3, #7
>>0x000140f4 <+1184>:  cmp r3, #4096   ; 0x1000
>>0x000140f8 <+1188>:  bcc 0x14110 
>>0x000140fc <+1192>:  sub r3, r3, #4096   ; 0x1000
>>0x00014100 <+1196>:  sub sp, sp, #4096   ; 0x1000
>>0x00014104 <+1200>:  cmp r3, #4096   ; 0x1000
>>0x00014108 <+1204>:  str r0, [sp, #8]
>>0x0001410c <+1208>:  bcs 0x140fc 
>>0x00014110 <+1212>:  ldr r7, [r11, #-56] ; 0xffc8
>>0x00014114 <+1216>:  sub sp, sp, r3
>>0x00014118 <+1220>:  mov r1, #0
>>0x0001411c <+1224>:  add r3, sp, #8
>>0x00014120 <+1228>:  mov r0, r3
>> => 0x00014124 <+1232>:  str r0, [sp, #8]
>> 
>> Andreas.
>> 
> Or better yet, include your .i and .s files in their entirety and the
> gcc -v output

This was generated with a very simple and incomplete backport of
-fstack-clash-protection to gcc7.  What I get with your full patches
with gcc8 looks correct.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 09/18/2017 10:09 AM, Andreas Schwab wrote:
> On Sep 18 2017, Jeff Law  wrote:
> 
>> Can you confirm if the probe was in the red zone vs the live areas on
>> the stack?
> 
> It overwrites a nearby variable.  sp + 8 happens to be the address of
> file_entries_new_size.
> 
>0x000140e8 <+1172>:  mov r6, sp
>0x000140ec <+1176>:  add r3, r3, #7
>0x000140f0 <+1180>:  bic r3, r3, #7
>0x000140f4 <+1184>:  cmp r3, #4096   ; 0x1000
>0x000140f8 <+1188>:  bcc 0x14110 
>0x000140fc <+1192>:  sub r3, r3, #4096   ; 0x1000
>0x00014100 <+1196>:  sub sp, sp, #4096   ; 0x1000
>0x00014104 <+1200>:  cmp r3, #4096   ; 0x1000
>0x00014108 <+1204>:  str r0, [sp, #8]
>0x0001410c <+1208>:  bcs 0x140fc 
>0x00014110 <+1212>:  ldr r7, [r11, #-56] ; 0xffc8
>0x00014114 <+1216>:  sub sp, sp, r3
>0x00014118 <+1220>:  mov r1, #0
>0x0001411c <+1224>:  add r3, sp, #8
>0x00014120 <+1228>:  mov r0, r3
> => 0x00014124 <+1232>:  str r0, [sp, #8]
> 
> Andreas.
> 
Or better yet, include your .i and .s files in their entirety and the
gcc -v output

Jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 09/18/2017 10:09 AM, Andreas Schwab wrote:
> On Sep 18 2017, Jeff Law  wrote:
> 
>> Can you confirm if the probe was in the red zone vs the live areas on
>> the stack?
> 
> It overwrites a nearby variable.  sp + 8 happens to be the address of
> file_entries_new_size.
> 
>0x000140e8 <+1172>:  mov r6, sp
>0x000140ec <+1176>:  add r3, r3, #7
>0x000140f0 <+1180>:  bic r3, r3, #7
>0x000140f4 <+1184>:  cmp r3, #4096   ; 0x1000
>0x000140f8 <+1188>:  bcc 0x14110 
>0x000140fc <+1192>:  sub r3, r3, #4096   ; 0x1000
>0x00014100 <+1196>:  sub sp, sp, #4096   ; 0x1000
>0x00014104 <+1200>:  cmp r3, #4096   ; 0x1000
>0x00014108 <+1204>:  str r0, [sp, #8]
>0x0001410c <+1208>:  bcs 0x140fc 
>0x00014110 <+1212>:  ldr r7, [r11, #-56] ; 0xffc8
>0x00014114 <+1216>:  sub sp, sp, r3
>0x00014118 <+1220>:  mov r1, #0
>0x0001411c <+1224>:  add r3, sp, #8
>0x00014120 <+1228>:  mov r0, r3
> => 0x00014124 <+1232>:  str r0, [sp, #8]
What is your exact configure target for gcc and glibc?  Additionally,
what's the git hash id of your glibc source tree?


I can't see how probing at sp+8 is ever valid here.  But the code I get
when compiling cache.i is significantly different than what you're
providing.  What I see is a probe at sp-4.

There's clearly something weird going on here.

jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Andreas Schwab]

On Sep 18 2017, Jeff Law  wrote:

> Can you confirm if the probe was in the red zone vs the live areas on
> the stack?

It overwrites a nearby variable.  sp + 8 happens to be the address of
file_entries_new_size.

   0x000140e8 <+1172>:  mov r6, sp
   0x000140ec <+1176>:  add r3, r3, #7
   0x000140f0 <+1180>:  bic r3, r3, #7
   0x000140f4 <+1184>:  cmp r3, #4096   ; 0x1000
   0x000140f8 <+1188>:  bcc 0x14110 
   0x000140fc <+1192>:  sub r3, r3, #4096   ; 0x1000
   0x00014100 <+1196>:  sub sp, sp, #4096   ; 0x1000
   0x00014104 <+1200>:  cmp r3, #4096   ; 0x1000
   0x00014108 <+1204>:  str r0, [sp, #8]
   0x0001410c <+1208>:  bcs 0x140fc 
   0x00014110 <+1212>:  ldr r7, [r11, #-56] ; 0xffc8
   0x00014114 <+1216>:  sub sp, sp, r3
   0x00014118 <+1220>:  mov r1, #0
   0x0001411c <+1224>:  add r3, sp, #8
   0x00014120 <+1228>:  mov r0, r3
=> 0x00014124 <+1232>:  str r0, [sp, #8]

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 09/18/2017 03:29 AM, Andreas Schwab wrote:
> On Jul 30 2017, Jeff Law  wrote:
> 
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probes or with a
>> rotated loop.  Blockage insns are also properly emitted for the dynamic
>> area probes and the dynamic area probing now supports targets that may
>> make optimistic assumptions in their prologues.  Finally it uses the new
>> param to control the probing interval.
>>
>> Tests were updated to explicitly specify the guard and probing interval.
>>  New test to check inline/unrolled probes as well as rotated loop.
> 
> Does that work correctly when the VLA is smaller than the probe size
> (word_mode by default)?  I see a failure in glibc on armv7 where
> ldconfig is using a zero-size VLA, which is invalid in C, but it could
> also end up using a VLA of size 1.
And in the case where the allocation is nonzero, but less than a word,
isn't its size rounded up to STACK_BOUNDARY which I'd expect to be word.

Jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 09/18/2017 03:29 AM, Andreas Schwab wrote:
> On Jul 30 2017, Jeff Law  wrote:
> 
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probes or with a
>> rotated loop.  Blockage insns are also properly emitted for the dynamic
>> area probes and the dynamic area probing now supports targets that may
>> make optimistic assumptions in their prologues.  Finally it uses the new
>> param to control the probing interval.
>>
>> Tests were updated to explicitly specify the guard and probing interval.
>>  New test to check inline/unrolled probes as well as rotated loop.
> 
> Does that work correctly when the VLA is smaller than the probe size
> (word_mode by default)?  I see a failure in glibc on armv7 where
> ldconfig is using a zero-size VLA, which is invalid in C, but it could
> also end up using a VLA of size 1.
For a dynamic allocation of size 0, we should be probing into the red
zone.  Alternately we could emit the branch around the probing bits.
I'd need to think about how that interacts with quirks of the aarch64
outgoing argument probing conventions though.

Can you confirm if the probe was in the red zone vs the live areas on
the stack?  The latter would be a serious issue obviously and I'd like
to track it down.  A testcase would be helpful.

Jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Joseph Myers]

On Mon, 18 Sep 2017, Andreas Schwab wrote:

> Does that work correctly when the VLA is smaller than the probe size
> (word_mode by default)?  I see a failure in glibc on armv7 where
> ldconfig is using a zero-size VLA, which is invalid in C, but it could
> also end up using a VLA of size 1.

FWIW, I'd consider zero-size VLAs (and VLAs with a positive dimension but 
whose elements are zero-size) to be a valid use of the GNU extension of 
zero-size objects - but still appropriate for -fsanitize=vla-bound to 
detect.  (But any enabled-by-default checks for VLA sizes, as discussed in 
bug 68065, ought to allow zero size.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 09/18/2017 03:29 AM, Andreas Schwab wrote:
> On Jul 30 2017, Jeff Law  wrote:
> 
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probes or with a
>> rotated loop.  Blockage insns are also properly emitted for the dynamic
>> area probes and the dynamic area probing now supports targets that may
>> make optimistic assumptions in their prologues.  Finally it uses the new
>> param to control the probing interval.
>>
>> Tests were updated to explicitly specify the guard and probing interval.
>>  New test to check inline/unrolled probes as well as rotated loop.
> 
> Does that work correctly when the VLA is smaller than the probe size
> (word_mode by default)?  I see a failure in glibc on armv7 where
> ldconfig is using a zero-size VLA, which is invalid in C, but it could
> also end up using a VLA of size 1.
I don't have a test for that, but can probably create one.

ISTM that if the size is variable and zero at runtime, then we need to
either allocate a small chunk and probe or avoid probing.

jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Andreas Schwab]

On Jul 30 2017, Jeff Law  wrote:

> This patch introduces generic mechanisms to protect the dynamically
> allocated stack space against stack-clash attacks.
>
> Changes since V2:
>
> Dynamic allocations can be emitted as unrolled inlined probes or with a
> rotated loop.  Blockage insns are also properly emitted for the dynamic
> area probes and the dynamic area probing now supports targets that may
> make optimistic assumptions in their prologues.  Finally it uses the new
> param to control the probing interval.
>
> Tests were updated to explicitly specify the guard and probing interval.
>  New test to check inline/unrolled probes as well as rotated loop.

Does that work correctly when the VLA is smaller than the probe size
(word_mode by default)?  I see a failure in glibc on armv7 where
ldconfig is using a zero-size VLA, which is invalid in C, but it could
also end up using a VLA of size 1.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

On 08/18/2017 08:05 AM, Richard Biener wrote:
> On Mon, Jul 31, 2017 at 7:38 AM, Jeff Law  wrote:
>>
>> This patch introduces generic mechanisms to protect the dynamically
>> allocated stack space against stack-clash attacks.
>>
>> Changes since V2:
>>
>> Dynamic allocations can be emitted as unrolled inlined probes or with a
>> rotated loop.  Blockage insns are also properly emitted for the dynamic
>> area probes and the dynamic area probing now supports targets that may
>> make optimistic assumptions in their prologues.  Finally it uses the new
>> param to control the probing interval.
>>
>> Tests were updated to explicitly specify the guard and probing interval.
>>  New test to check inline/unrolled probes as well as rotated loop.
>>
>>
>>
>> * explow.c: Include "params.h".
>> (anti_adjust_stack_and_probe_stack_clash): New function.
>> (get_stack_check_protect): Likewise.
>> (compute_stack_clash_protection_loop_data): Likewise.
>> (emit_stack_clash_protection_loop_start): Likewise.
>> (emit_stack_clash_protection_loop_end): Likewise.
>> (allocate_dynamic_stack_space): Use get_stack_check_protect.
>> Use anti_adjust_stack_and_probe_stack_clash.
>> * explow.h (compute_stack_clash_protection_loop_data): Prototype.
>> (emit_stack_clash_protection_loop_start): Likewise.
>> (emit_stack_clash_protection_loop_end): Likewise.
>> * rtl.h (get_stack_check_protect): Prototype.
>> * defaults.h (STACK_CLASH_PROTECTION_NEEDS_FINAL_DYNAMIC_PROBE):
>> Define new default.
>> * doc/tm.texi.in (STACK_CLASH_PROTECTION_NEEDS_FINAL_DYNAMIC_PROBE):
>> Define.
> 
> Please make this a hook instead of a target macro.
Will do.  I should have known better :-)


> 
> Besides this it looks good (I trust you on the RTL details).
THanks.


Jeff

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Richard Biener]

On Mon, Jul 31, 2017 at 7:38 AM, Jeff Law  wrote:
>
> This patch introduces generic mechanisms to protect the dynamically
> allocated stack space against stack-clash attacks.
>
> Changes since V2:
>
> Dynamic allocations can be emitted as unrolled inlined probes or with a
> rotated loop.  Blockage insns are also properly emitted for the dynamic
> area probes and the dynamic area probing now supports targets that may
> make optimistic assumptions in their prologues.  Finally it uses the new
> param to control the probing interval.
>
> Tests were updated to explicitly specify the guard and probing interval.
>  New test to check inline/unrolled probes as well as rotated loop.
>
>
>
> * explow.c: Include "params.h".
> (anti_adjust_stack_and_probe_stack_clash): New function.
> (get_stack_check_protect): Likewise.
> (compute_stack_clash_protection_loop_data): Likewise.
> (emit_stack_clash_protection_loop_start): Likewise.
> (emit_stack_clash_protection_loop_end): Likewise.
> (allocate_dynamic_stack_space): Use get_stack_check_protect.
> Use anti_adjust_stack_and_probe_stack_clash.
> * explow.h (compute_stack_clash_protection_loop_data): Prototype.
> (emit_stack_clash_protection_loop_start): Likewise.
> (emit_stack_clash_protection_loop_end): Likewise.
> * rtl.h (get_stack_check_protect): Prototype.
> * defaults.h (STACK_CLASH_PROTECTION_NEEDS_FINAL_DYNAMIC_PROBE):
> Define new default.
> * doc/tm.texi.in (STACK_CLASH_PROTECTION_NEEDS_FINAL_DYNAMIC_PROBE):
> Define.

Please make this a hook instead of a target macro.

Besides this it looks good (I trust you on the RTL details).

Thanks,
Richard.

> * doc/tm.texi: Rebuilt.
>
> * config/aarch64/aarch64.c (aarch64_expand_prologue): Use
> get_stack_check_protect.
> * config/alpha/alpha.c (alpha_expand_prologue): Likewise.
> * config/arm/arm.c (arm_expand_prologue): Likewise.
> * config/i386/i386.c (ix86_expand_prologue): Likewise.
> * config/ia64/ia64.c (ia64_expand_prologue): Likewise.
> * config/mips/mips.c (mips_expand_prologue): Likewise.
> * config/powerpcspe/powerpcspe.c (rs6000_emit_prologue): Likewise.
> * config/rs6000/rs6000.c (rs6000_emit_prologue): Likewise.
> * config/sparc/sparc.c (sparc_expand_prologue): Likewise.
>
>
> testsuite
>
> * gcc.dg/stack-check-3.c: New test.
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index ef1b5a8..0a8b40a 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -3676,12 +3676,14 @@ aarch64_expand_prologue (void)
>  {
>if (crtl->is_leaf && !cfun->calls_alloca)
> {
> - if (frame_size > PROBE_INTERVAL && frame_size > STACK_CHECK_PROTECT)
> -   aarch64_emit_probe_stack_range (STACK_CHECK_PROTECT,
> -   frame_size - STACK_CHECK_PROTECT);
> + if (frame_size > PROBE_INTERVAL
> + && frame_size > get_stack_check_protect ())
> +   aarch64_emit_probe_stack_range (get_stack_check_protect (),
> +   (frame_size
> +- get_stack_check_protect ()));
> }
>else if (frame_size > 0)
> -   aarch64_emit_probe_stack_range (STACK_CHECK_PROTECT, frame_size);
> +   aarch64_emit_probe_stack_range (get_stack_check_protect (), 
> frame_size);
>  }
>
>aarch64_sub_sp (IP0_REGNUM, initial_adjust, true);
> diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
> index 00a69c1..91f3d7c 100644
> --- a/gcc/config/alpha/alpha.c
> +++ b/gcc/config/alpha/alpha.c
> @@ -7741,7 +7741,7 @@ alpha_expand_prologue (void)
>
>probed_size = frame_size;
>if (flag_stack_check)
> -probed_size += STACK_CHECK_PROTECT;
> +probed_size += get_stack_check_protect ();
>
>if (probed_size <= 32768)
>  {
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index c6101ef..9822ca7 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -21680,13 +21680,13 @@ arm_expand_prologue (void)
>
>if (crtl->is_leaf && !cfun->calls_alloca)
> {
> - if (size > PROBE_INTERVAL && size > STACK_CHECK_PROTECT)
> -   arm_emit_probe_stack_range (STACK_CHECK_PROTECT,
> -   size - STACK_CHECK_PROTECT,
> + if (size > PROBE_INTERVAL && size > get_stack_check_protect ())
> +   arm_emit_probe_stack_range (get_stack_check_protect (),
> +   size - get_stack_check_protect (),
> regno, live_regs_mask);
> }
>else if (size > 0)
> -   arm_emit_probe_stack_range (STACK_CHECK_PROTECT, size,
> +   arm_emit_probe_stack_range (get_stack_check_protect (), size,
> 

[PATCH][RFA/RFC] Stack clash mitigation patch 02/08 - V3

[Jeff Law]

This patch introduces generic mechanisms to protect the dynamically
allocated stack space against stack-clash attacks.

Changes since V2:

Dynamic allocations can be emitted as unrolled inlined probes or with a
rotated loop.  Blockage insns are also properly emitted for the dynamic
area probes and the dynamic area probing now supports targets that may
make optimistic assumptions in their prologues.  Finally it uses the new
param to control the probing interval.

Tests were updated to explicitly specify the guard and probing interval.
 New test to check inline/unrolled probes as well as rotated loop.


* explow.c: Include "params.h".
(anti_adjust_stack_and_probe_stack_clash): New function.
(get_stack_check_protect): Likewise.
(compute_stack_clash_protection_loop_data): Likewise.
(emit_stack_clash_protection_loop_start): Likewise.
(emit_stack_clash_protection_loop_end): Likewise.
(allocate_dynamic_stack_space): Use get_stack_check_protect.
Use anti_adjust_stack_and_probe_stack_clash.
* explow.h (compute_stack_clash_protection_loop_data): Prototype.
(emit_stack_clash_protection_loop_start): Likewise.
(emit_stack_clash_protection_loop_end): Likewise.
* rtl.h (get_stack_check_protect): Prototype.
* defaults.h (STACK_CLASH_PROTECTION_NEEDS_FINAL_DYNAMIC_PROBE):
Define new default.
* doc/tm.texi.in (STACK_CLASH_PROTECTION_NEEDS_FINAL_DYNAMIC_PROBE):
Define.
* doc/tm.texi: Rebuilt.

* config/aarch64/aarch64.c (aarch64_expand_prologue): Use
get_stack_check_protect.
* config/alpha/alpha.c (alpha_expand_prologue): Likewise.
* config/arm/arm.c (arm_expand_prologue): Likewise.
* config/i386/i386.c (ix86_expand_prologue): Likewise.
* config/ia64/ia64.c (ia64_expand_prologue): Likewise.
* config/mips/mips.c (mips_expand_prologue): Likewise.
* config/powerpcspe/powerpcspe.c (rs6000_emit_prologue): Likewise.
* config/rs6000/rs6000.c (rs6000_emit_prologue): Likewise.
* config/sparc/sparc.c (sparc_expand_prologue): Likewise.


testsuite

* gcc.dg/stack-check-3.c: New test.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ef1b5a8..0a8b40a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3676,12 +3676,14 @@ aarch64_expand_prologue (void)
 {
   if (crtl->is_leaf && !cfun->calls_alloca)
{
- if (frame_size > PROBE_INTERVAL && frame_size > STACK_CHECK_PROTECT)
-   aarch64_emit_probe_stack_range (STACK_CHECK_PROTECT,
-   frame_size - STACK_CHECK_PROTECT);
+ if (frame_size > PROBE_INTERVAL
+ && frame_size > get_stack_check_protect ())
+   aarch64_emit_probe_stack_range (get_stack_check_protect (),
+   (frame_size
+- get_stack_check_protect ()));
}
   else if (frame_size > 0)
-   aarch64_emit_probe_stack_range (STACK_CHECK_PROTECT, frame_size);
+   aarch64_emit_probe_stack_range (get_stack_check_protect (), frame_size);
 }
 
   aarch64_sub_sp (IP0_REGNUM, initial_adjust, true);
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 00a69c1..91f3d7c 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -7741,7 +7741,7 @@ alpha_expand_prologue (void)
 
   probed_size = frame_size;
   if (flag_stack_check)
-probed_size += STACK_CHECK_PROTECT;
+probed_size += get_stack_check_protect ();
 
   if (probed_size <= 32768)
 {
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index c6101ef..9822ca7 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -21680,13 +21680,13 @@ arm_expand_prologue (void)
 
   if (crtl->is_leaf && !cfun->calls_alloca)
{
- if (size > PROBE_INTERVAL && size > STACK_CHECK_PROTECT)
-   arm_emit_probe_stack_range (STACK_CHECK_PROTECT,
-   size - STACK_CHECK_PROTECT,
+ if (size > PROBE_INTERVAL && size > get_stack_check_protect ())
+   arm_emit_probe_stack_range (get_stack_check_protect (),
+   size - get_stack_check_protect (),
regno, live_regs_mask);
}
   else if (size > 0)
-   arm_emit_probe_stack_range (STACK_CHECK_PROTECT, size,
+   arm_emit_probe_stack_range (get_stack_check_protect (), size,
regno, live_regs_mask);
 }
 
@@ -27854,7 +27854,7 @@ arm_frame_pointer_required (void)
{
  /* We don't have the final size of the frame so adjust.  */
  size += 32 * UNITS_PER_WORD;
- if (size > PROBE_INTERVAL && size > STACK_CHECK_PROTECT)
+ if (size > PROBE_INTERVAL && size > get_stack_check_protect ())
return