[Bug other/112897] Have a configure option for all common flags used by default on distros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112897 --- Comment #2 from Agostino Sarubbo --- I don't know if I was able to provide the concept, but in other words if we know that something like -fstack-clash-protection is widely used nowadays, it make no sense rebase patches for 10 years and then in the 2033 make the proper configure option :) > What's the flag you want to enable this time? I'm not a gcc downstream maintainer so I can speak for what I can see as external people, so you might want to involve downstream maintainers. >From what I can see I'd say that a starting point is: -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=3 -fstack-clash-protection -fcf-protection -z,relro / -z now _GLIBCXX_ASSERTIONS -Wformat -Wformat-security
[Bug other/112897] New: Have a configure option for all common flags used by default on distros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112897 Bug ID: 112897 Summary: Have a configure option for all common flags used by default on distros Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ago at gentoo dot org Target Milestone: --- Historically, distro like Gentoo Hardened, used patches to make gcc compile by default with pie/ssp. After a lot of years these patches are not anymore needed because they have been 'translated' into a configure option by upstream (-enable-default-pie --enable-default-ssp), so I'm wondering about create a proper configure option for the mostly used flags used on distros. That means do the job once upstream, and then distros can use the proper configure option while atm distros need to rebase patches on each gcc bump. This is what I have found from a rapid search: Debian: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/gcc-distro-specs.diff Fedora (there are other unrelated patches): https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/g/gcc-13.2.1-5.fc40.src.rpm Gentoo (there are other unrelated patches): https://gitweb.gentoo.org/proj/gcc-patches.git/tree/13.2.0/gentoo What do you think?
[Bug tree-optimization/112635] stack smash protection does not work when code is compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112635 Agostino Sarubbo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Agostino Sarubbo --- (In reply to Richard Biener from comment #1) > Yep, GCC fixes the code for you by eliding 'buf' With a tool like https://godbolt.org/ I now get what you mean, so I'm closing this as invalid by myself
[Bug tree-optimization/112635] stack smash protection does not work when code is compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112635 --- Comment #2 from Agostino Sarubbo --- (In reply to Richard Biener from comment #1) > Yep, GCC fixes the code for you by eliding 'buf'. That's perfectly OK though > since the code invokes undefined behavior. > > I'm inclined to close this as INVALID/WONTFIX, it isn't really a bug > (but also not a feature you can rely on of course). Thanks for the response. So the question is: to have a reliable ssp, do I have to use -O0 ?
[Bug libgcc/112635] New: stack smash protection does not work when code is compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112635
Bug ID: 112635
Summary: stack smash protection does not work when code is
compiled with -O
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ago at gentoo dot org
Target Milestone: ---
If this is a known thing, please forgive me.
I was playing with the stack-smash protection and this is what I have found.
Please consider the following block of code:
#include
int main () {
char *buf[1];
buf[1] = "A (stack-based) buffer overflow";
printf("%s \n", buf[1]);
return 0;
}
If compiled with -fsanitize=address I get:
==24180==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f54c7600028 at pc 0x00401210 bp 0x7fff54f73180 sp 0x7fff54f73178
WRITE of size 8 at 0x7f54c7600028 thread T0
If compiled with -fstack-protector-strong I get:
A (stack-based) buffer overflow
*** stack smashing detected ***: terminated
Aborted
But while compiled with -fstack-protector-strong and -O1 (and also -O2/-O3/-Os)
I just get it working without any issue (it prints "A (stack-based) buffer
overflow")
So in the practice it does not work when -O is used.
I'm running gcc 13 on Gentoo, but I have reproduced this issue on ubuntu-22
(gcc-11.4.0), ubuntu-20 (gcc-9.4.0), and also centos-7 (gcc-4.8.5)
A side note:
I used checksec (https://github.com/slimm609/checksec.sh) basically a `readelf
-W -s a.out | grep "stack_chk_fail"` in this case to understand what happens
and I can see:
- when '-fstack-protector-strong' reports canary found (as expected)
- when '-fstack-protector-strong -O2' reports NO canary found
- when '-fstack-protector-all -O2' reports canary found but no 'stack smashing
detected' at runtime
[Bug other/112589] New: man gcc does not specify the default behavior of -fcf-protection when used without arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112589 Bug ID: 112589 Summary: man gcc does not specify the default behavior of -fcf-protection when used without arguments Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ago at gentoo dot org Target Milestone: --- man gcc says: -fcf-protection=[full|branch|return|none|check] However, at runtime, you can use -fcf-protection without any arguments, but the manual does not specify what is the default behavior in case of missing argument.
