public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/58245] New: -fstack-protector[-all] does not protect functions that call noreturn functions Date: Tue, 27 Aug 2013 02:06:00 -0000 [thread overview] Message-ID: <bug-58245-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245 Bug ID: 58245 Summary: -fstack-protector[-all] does not protect functions that call noreturn functions 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 This issue is almost identical to bug #23221, but affects functions whose executions end with a call to a noreturn function rather than a tail call. The simplest example is: #include <stdlib.h> int main() { exit(0); } When compiled with -fstack-protector-all, the function prologue will read and store the canary, but no check will be made before passing execution to exit. This is actually a major practical problem for some users of musl libc, because code like the above appears in many configure scripts, and musl libc uses weak symbols so as to avoid initializing stack-protector (and thereby avoid initializing the TLS register) if there is no reference to __stack_chk_fail. Due to this issue, the above code generates thread-pointer-relative (e.g. %fs-based on x86_64) accesses to read the canary, but no reference to __stack_chk_fail, and then crashes when run, leading to spurious configure failures. For the time being, I have informed users who wish to use -fstack-protector-all that they can add -fno-builtin-exit -D__noreturn__= to their CFLAGS, but this is an ugly workaround. It should be noted that this issue happens even at -O0. I think using noreturn for dead code removal at -O0 is highly undesirable; for instance, it would preclude proper debugging of issues caused by a function erroneously being marked noreturn and actually returning. However that matter probably deserves its own bug report...
next reply other threads:[~2013-08-27 2:06 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-27 2:06 bugdal at aerifal dot cx [this message] 2013-08-27 2:08 ` [Bug middle-end/58245] " bugdal at aerifal dot cx 2013-08-27 2:23 ` pinskia at gcc dot gnu.org 2013-08-27 2:35 ` bugdal at aerifal dot cx 2013-08-28 13:10 ` rose.garcia-eggl2fk at yopmail dot com 2013-10-01 14:07 ` timo.teras at iki dot fi 2013-10-01 15:44 ` jakub at gcc dot gnu.org 2013-10-01 17:18 ` bugdal at aerifal dot cx 2014-01-15 14:24 ` basile at opensource dot dyc.edu 2014-02-16 13:16 ` jackie.rosen at hushmail dot com 2022-07-13 22:49 ` pinskia at gcc dot gnu.org 2022-07-13 23:19 ` hjl.tools at gmail dot com 2022-07-13 23:19 ` hjl.tools at gmail dot com 2022-09-28 1:30 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-58245-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).