[00/19] aarch64: Fix -fstack-protector issue

  This series of patches fixes deficiencies in GCC's -fstack-protector
implementation for AArch64 when using dynamically allocated stack space.
This is CVE-2023-4039.  See:

https://developer.arm.com/Arm%20Security%20Center/GCC%20Stack%20Protector%20Vulnerability%20AArch64
https://github.com/metaredteam/external-disclosures/security/advisories/GHSA-x7ch-h5rf-w2mf

for more details.

The fix is to put the saved registers above the locals area when
-fstack-protector is used.

The series also fixes a stack-clash problem that I found while working
on the CVE.  In unpatched sources, the stack-clash problem would only
trigger for unrealistic numbers of arguments (8K 64-bit arguments, or an
equivalent).  But it would be a more significant issue with the new
-fstack-protector frame layout.  It's therefore important that both
problems are fixed together.

Some reorganisation of the code seemed necessary to fix the problems in a
cleanish way.  The series is therefore quite long, but only a handful of
patches should have any effect on code generation.

See the individual patches for a detailed description.

Tested on aarch64-linux-gnu. Pushed to trunk and to all active branches.
I've also pushed backports to GCC 7+ to vendors/ARM/heads/CVE-2023-4039.

Richard Sandiford (19):
  aarch64: Use local frame vars in shrink-wrapping code
  aarch64: Avoid a use of callee_offset
  aarch64: Explicitly handle frames with no saved registers
  aarch64: Add bytes_below_saved_regs to frame info
  aarch64: Add bytes_below_hard_fp to frame info
  aarch64: Tweak aarch64_save/restore_callee_saves
  aarch64: Only calculate chain_offset if there is a chain
  aarch64: Rename locals_offset to bytes_above_locals
  aarch64: Rename hard_fp_offset to bytes_above_hard_fp
  aarch64: Tweak frame_size comment
  aarch64: Measure reg_offset from the bottom of the frame
  aarch64: Simplify top of frame allocation
  aarch64: Minor initial adjustment tweak
  aarch64: Tweak stack clash boundary condition
  aarch64: Put LR save probe in first 16 bytes
  aarch64: Simplify probe of final frame allocation
  aarch64: Explicitly record probe registers in frame info
  aarch64: Remove below_hard_fp_saved_regs_size
  aarch64: Make stack smash canary protect saved registers

 gcc/config/aarch64/aarch64.cc                 | 518 ++++++++++--------
 gcc/config/aarch64/aarch64.h                  |  44 +-
 .../aarch64/stack-check-prologue-17.c         |  55 ++
 .../aarch64/stack-check-prologue-18.c         | 100 ++++
 .../aarch64/stack-check-prologue-19.c         | 100 ++++
 .../aarch64/stack-check-prologue-20.c         |   3 +
 .../gcc.target/aarch64/stack-protector-8.c    |  95 ++++
 .../gcc.target/aarch64/stack-protector-9.c    |  33 ++
 .../aarch64/sve/pcs/stack_clash_3.c           |   6 +-
 9 files changed, 699 insertions(+), 255 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/stack-check-prologue-17.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/stack-check-prologue-18.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/stack-check-prologue-19.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/stack-check-prologue-20.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/stack-protector-8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/stack-protector-9.c
  

On 2023-09-12 11:25, Richard Sandiford via Gcc-patches wrote:
> This series of patches fixes deficiencies in GCC's -fstack-protector
> implementation for AArch64 when using dynamically allocated stack space.
> This is CVE-2023-4039.  See:
> 

While this is a legitimate missed hardening, I'm not sure if this 
qualifies as a CVE-worthy vulnerability since correct programs won't 
actually be exploitable due to this.  This is essentially the kind of 
thing that the "Security features implemented in GCC" section in the 
proposed security policy[1] describes.

Thanks,
Sid

[1] 
https://inbox.sourceware.org/gcc-patches/ba133293-a7e8-8fe4-e1ba-7129b9e103f7@gotplt.org/