[Bug middle-end/93509] New: Stack protector should offer trap-only handling

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509

            Bug ID: 93509
           Summary: Stack protector should offer trap-only handling
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Presently stack protector functionality depends on making a call to
__stack_chk_fail (possibly via __stack_chk_fail_local to avoid PLT-call-ABI
constraint in the caller). This is less secure than it could be, since it
depends on the ability to make function calls (and possibly operate on global
data and make syscalls in the callee) in a process whose state is compromised.
For example the GOT entries used by PLT could be clobbered or %gs:0x10 (i386
syscall vector) could be clobbered by the same stack-based overflow that caused
the stack protector event in the first place.

In https://gcc.gnu.org/ml/gcc/2020-01/msg00483.html where the topic is being
discussed for other reasons (contract between gcc and libc for where these
symbols are provided), I proposed that GCC should offer an option to emit a
trapping instruction directly, instead of making a function call, analogous to
-fsanitize-undefined-trap-on-error for UBSan. This would work well on all
targets where __builtin_trap is defined, but would regress (requiring PLT call)
on targets where it uses the default abort() definition (are there any relevant
ones?). Segher Boessenkool then requested I file this here on the GCC tracker.

Note: I'm filing this for middle-end because that was my best guess of where
GCC handles it, but it's possible all this logic is repeated in each target or
takes place somewhere else entirely; if so please reassign to appropriate
component.