public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/58245] New: -fstack-protector[-all] does not protect functions that call noreturn functions
@ 2013-08-27  2:06 bugdal at aerifal dot cx
  2013-08-27  2:08 ` [Bug middle-end/58245] " bugdal at aerifal dot cx
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: bugdal at aerifal dot cx @ 2013-08-27  2:06 UTC (permalink / raw)
  To: gcc-bugs

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...


^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-09-28  1:30 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-27  2:06 [Bug middle-end/58245] New: -fstack-protector[-all] does not protect functions that call noreturn functions bugdal at aerifal dot cx
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

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).