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.