[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2022-09-27 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #13 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:a25982ada523689c8745d7fb4b1b93c8f5dab2e7

commit r13-2909-ga25982ada523689c8745d7fb4b1b93c8f5dab2e7
Author: H.J. Lu 
Date:   Thu Jul 14 08:23:38 2022 -0700

stack-protector: Check stack canary before throwing exception

Check stack canary before throwing exception to avoid stack corruption.

gcc/

PR middle-end/58245
* calls.cc: Include "tree-eh.h".
(expand_call): Check stack canary before throwing exception.

gcc/testsuite/

PR middle-end/58245
* g++.dg/fstack-protector-strong.C: Adjusted.
* g++.dg/pr58245-1.C: New test.

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2022-07-13 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-13
Version|unknown |10.3.1

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2022-07-13 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #12 from H.J. Lu  ---
Created attachment 53294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53294=edit
A patch

Something like this?

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2022-07-13 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #11 from Andrew Pinski  ---
*** Bug 106288 has been marked as a duplicate of this bug. ***

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2018-10-18 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #10 from Rich Felker  ---
Since musl 1.1 introduced unconditional setup of thread pointer, the
previously-reported consequence is no longer relevant with modern versions.
However it's still either a missed optimization (emitting useless canary load
despite the fact that there's no code to check the canary) or missed hardening
(checking canary before leaving via a noreturn function) and thus seems
interesting still.

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2014-02-16 Thread jackie.rosen at hushmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

Jackie Rosen jackie.rosen at hushmail dot com changed:

   What|Removed |Added

 CC||jackie.rosen at hushmail dot 
com

--- Comment #9 from Jackie Rosen jackie.rosen at hushmail dot com ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2014-01-15 Thread basile at opensource dot dyc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

Anthony G. Basile basile at opensource dot dyc.edu changed:

   What|Removed |Added

 CC||basile at opensource dot 
dyc.edu

--- Comment #8 from Anthony G. Basile basile at opensource dot dyc.edu ---
Gentoo's hardened toolchain is stumbling on this bug and its a blocker for us
to get musl + gentoo working nicely.  Has there been any movement on it?


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-10-01 Thread timo.teras at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #5 from Timo Teräs timo.teras at iki dot fi ---
I have the same issue and confirm this issue. Any ideas how to fix it properly?

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-10-01 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
I don't see how this can be considered a GCC bug.
GCC doesn't check the canary before any other functions in the body of the
function, the reason for checking the stack canary is to prevent using
overwritten return addresses on the stack, but noreturn function doesn't
return, so it is irrelevant if the stack has been overwritten (except for what
would matter inside of the function itself, but we don't check it for any other
function either in the middle of functions).


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-10-01 Thread bugdal at aerifal dot cx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #7 from Rich Felker bugdal at aerifal dot cx ---
I claim it's a bug in that GCC should _either_ check the canary at some point,
or eliminate the code that's loading the canary to begin with since it will
never be checked.


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-08-28 Thread rose.garcia-eggl2fk at yopmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

Rose Garcia rose.garcia-eggl2fk at yopmail dot com changed:

   What|Removed |Added

 CC||rose.garcia-eggl2fk@yopmail
   ||.com

--- Comment #4 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com ---
the place to get only the GCC patches for musl is
https://github.com/GregorR/musl-gcc-patches though.


btw, some debugging has shown that
stack_protect_prologue() and
stack_protect_epilogue() are both called, so it looks as if it's a later pass
that decides to eliminate the dead code of the epilogue, but not the one of
the prologue.

any hints where in the code this could happen is appreciated.


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-08-26 Thread bugdal at aerifal dot cx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #1 from Rich Felker bugdal at aerifal dot cx ---
One more thing: I would be happy with either of two solutions, either:

(1) Checking the canary before calling a noreturn function, just like
performing a check before a tail-call, or

(2) Eliminating the dead-code-removal of the function epilogue at -O0, and for
non-zero -O levels, adding an optimization to remove the canary loading from
the prologue if no epilogue to check the canary is to be generated.


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-08-26 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
The best solution: Don't use the same triplet as the GNU (glibc) one.  Have
musl have its own triplet.


[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

2013-08-26 Thread bugdal at aerifal dot cx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

--- Comment #3 from Rich Felker bugdal at aerifal dot cx ---
We already do that; the patch is in the musl-cross repo here:

https://bitbucket.org/GregorR/musl-cross or
https://github.com/GregorR/musl-cross

However, we want the stack-protector behavior for GCC with musl to be the same
as with glibc, using the TLS canary and __stack_chk_fail function in libc
rather than a separate libssp. In all real-world, nontrivial code, everything
works fine. The only failure of empty programs like the above which just call
exit, which, when combined with -fstack-protector-all, cause failure.

In any case, the failure of configure scripts with musl is just one symptom of
the problem: useless loads of the canary without a corresponding check of the
canary. From a security standpoint, I feel like checking the canary before
calling a function that won't return would be the best possible behavior, so
that every function gets a check. However, if doing this isn't deemed
worthwhile, I think the canary load, which is dead code without a subsequent
check, should be optimized out.