Description
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:
-fcf-protection=full
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
- gh-112301: fix compiler warning about a possible use of an uninitialized variable #112308
- gh-112301: Enable compiler flags with low performance impact and no warnings #120975
- gh-112301: Add fortify source level 3 to default compiler options #121520
- gh-112301: Compiler warning management tooling #121730
- gh-112301:
-fstack-protector-strongis also needed inLDFLAGSon Solaris/Illumos #121979 - gh-112301: Revert "Add fortify source level 3 to default compiler options (gh-121520) #122112
- gh-112301: Make fortify source option check -Werror #122141
- gh-112301: Add macOS warning tracking tooling #122211
- gh-112301: Add argument aliases and tee compiler output for check warnings #122465
- gh-112301: Add -Wformat=2 compiler option to NODIST #122474
- gh-112301: Add Warning Count to Warning Check Tooling #122711
- gh-112301: Update disable safety and enable slow safety configure options documentation #122758
- gh-112301: Enable warning emitting options and ignore warnings in CI #123020
- Revert "gh-112301: Enable warning emitting options and ignore warnings in CI (#123020)" #124065
- gh-112301: Use literal format strings in unicode_fromformat_arg #124203