Feature or enhancement
Proposal:
At a recent meeting of OpenSSF's Memory Safety SIG, I became aware of the C/C++ hardening guide they are putting together.
At a high-level, they recommend compiling with the following flags:
-O2 -Wall -Wformat=2 -Wconversion -Wtrampolines -Wimplicit-fallthrough \
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 \
-D_GLIBCXX_ASSERTIONS \
-fstrict-flex-arrays=3 \
-fstack-clash-protection -fstack-protector-strong \
-Wl,-z,nodlopen -Wl,-z,noexecstack \
-Wl,-z,relro -Wl,-z,now \
-fPIE -pie -fPIC -shared
(-shared doesn't really make sense as a global CFLAG, so I removed it.)
When compiling on most x86 architectures (amd64, i386 and x32), add:
At @sethmlarson's urging, I compiled CPython on Linux/x86_64/gcc with these flags. From the complete build log, there are 3,084 warnings, but otherwise the result builds and passes all unit tests.
The warnings are of these types: (EDIT: Table updated to not double count the same line)
| warning type |
count |
| sign-conversion |
2,341 |
| conversion |
595 |
| array-bounds= |
131 |
| format-nonliteral |
11 |
| stringop-overflow= |
2 |
| float-conversion |
2 |
| stringop-overread |
1 |
| maybe-uninitialized |
1 |
| total |
3,084 |
**Top warnings per file.**
| filename |
count |
| ./Modules/binascii.c |
208 |
| Objects/unicodeobject.c |
142 |
| ./Include/internal/pycore_runtime_init.h |
128 |
| Parser/parser.c |
114 |
| ./Modules/_decimal/libmpdec/mpdecimal.c |
94 |
| ./Modules/posixmodule.c |
85 |
| ./Modules/socketmodule.c |
76 |
| ./Modules/_pickle.c |
75 |
| Objects/longobject.c |
65 |
| ./Modules/arraymodule.c |
49 |
| total |
3,084 |
I am not a security expert, so I don't know a good way to assess how many of these are potentially exploitable, and how many are harmless false positives. Some are probably un-resolvable (format-literal is pretty hard to avoid when wrapping sprintf, for example).
At a high level, I think the process to address these and make incremental progress maybe looks something like:
- Pick one of the warning types, and assess how many false positives it gives and how onerous it is to fix them. From this, build concensus about whether it's worth addressing.
- Fix all of the existing instances.
- Turn that specific warning into an error so it doesn't creep back in.
But this is just to start the discussion about how to move forward.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
Feature or enhancement
Proposal:
At a recent meeting of OpenSSF's Memory Safety SIG, I became aware of the C/C++ hardening guide they are putting together.
At a high-level, they recommend compiling with the following flags:
(
-shareddoesn't really make sense as a global CFLAG, so I removed it.)When compiling on most x86 architectures (amd64, i386 and x32), add:
At @sethmlarson's urging, I compiled CPython on Linux/x86_64/gcc with these flags. From the complete build log, there are 3,084 warnings, but otherwise the result builds and passes all unit tests.
The warnings are of these types: (EDIT: Table updated to not double count the same line)
**Top warnings per file.**
I am not a security expert, so I don't know a good way to assess how many of these are potentially exploitable, and how many are harmless false positives. Some are probably un-resolvable (format-literal is pretty hard to avoid when wrapping
sprintf, for example).At a high level, I think the process to address these and make incremental progress maybe looks something like:
But this is just to start the discussion about how to move forward.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
-fstack-protector-strongis also needed inLDFLAGSon Solaris/Illumos #121979