airbus-seclab / c-compiler-security Goto Github PK

Hello,
Thanks for this repo, it's great!
I think there is a small error in the clang TL;DR section of the README; it seems that the -Wlogical-op option is GCC only and is not supported by clang. It is not listed in the reference.
This is what I get with clang-12 -Wlogical-op foo.c -o foo:

warning: unknown warning option '-Wlogical-op'; did you mean '-Wlong-long'? [-Wunknown-warning-option]

First of all, thank you very much for this useful list and explanations; it really helps extracting maximum power out of compilers and sanitizers.

I have a few questions about some options.

I have a Fedora 34 with Clang 12 installed, according to clang -v:

clang version 12.0.1 (Fedora 12.0.1-1.fc34)
Target: x86_64-unknown-linux-gnu

I tried compiling a simple program using the options in the "Clang TL;DR" list, while also using the options for "AddressSanitizer + UndefinedBehaviorSanitizer", that is:

clang err.c -O2 -Walloca -Wcast-qual -Wconversion -Wformat=2 -Wformat-security -Wnull-dereference \
-Wstack-protector -Wstrict-overflow=3 -Wvla -Warray-bounds -Warray-bounds-pointer-arithmetic \
-Wassign-enum -Wbad-function-cast -Wconditional-uninitialized -Wconversion -Wfloat-equal \
-Wformat-type-confusion -Widiomatic-parentheses -Wimplicit-fallthrough -Wloop-analysis -Wpointer-arith \
-Wshift-sign-overflow -Wshorten-64-to-32 -Wswitch-enum -Wtautological-constant-in-range-compare \
-Wunreachable-code-aggressive -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fsanitize=safe-stack \
-fPIE -fstack-clash-protection -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,separate-code -fsanitize=address \
-fsanitize=leak -fno-omit-frame-pointer -fsanitize=undefined -fsanitize=bounds-strict \
-fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fsanitize=integer -fsanitize-no-recover

I got the following error message:

clang-12: error: unknown argument: '-fsanitize-no-recover'
clang-12: error: unsupported argument 'bounds-strict' to option 'fsanitize='
clang-12: error: invalid argument '-fsanitize=safe-stack' not allowed with '-fsanitize=leak'

Indeed, there is a mention elsewhere in the page of option -fno-sanitize-recover, so it seems that -fsanitize-no-recover might be a typo. Could you please confirm it? Or is it a different option?

About -fsanitize=bounds-strict, I found references to it on Google but only for GCC, not for Clang/LLVM. But I couldn't find a definitive list of options concerning all sanitizers, so maybe my Clang is missing them? Could you please confirm, or offer more details about the version of Clang you are using where this option works?

About the incompatibility between SafeStack and Leak, I couldn't find any mentions in their documentation, but they don't typically list all incompatibilities (which would be hard to do and keep up-to-date), so I wonder if I took a bit too literally the comment "Run debug/test builds with sanitizers (in addition to the flags above)", by combining all flags. Or is there a way to run them together? I'd appreciate if you could clarify it (or just confirm that, indeed, mixing both does not work).

Finally, after removing -fsanitize=leak, I still got an error: clang-12: error: invalid argument '-fsanitize=safe-stack' not allowed with '-fsanitize=address'. So, I ended up removing -fsanitize=safe-stack and putting back -fsanitize=leak, and this time I had no more errors. Once again, I wonder if this is specific to my configuration.

-Wstrict-overflow=3 pas de description de l'option (chapitre GCC). Normal ?

replace"you" by "your" in
...to compile you C Code using...

Found it difficult to read. Suggestion:
Warn about sign mismatches in format functions between their format specifiers and actual parameters

the reference https://danluu.com/integer-overflow/ seems quite old. It mentions clang 3.8 and gcc 5 and refers to John Reger's blog post from 2014

-D_FORTIFY_SOURCE=3 exists now.

-ftrivial-auto-var-init=zero is in GCC 12+ and Clang.

-fsanitize=bounds -fsanitize-undefined-trap-on-error for trivial checking of known-size arrays.

-fstrict-flex-arrays will be in GCC 13+ and Clang 16+, but likely requires some very careful management of some header files, especially anything using the very ancient struct sockaddr. But it'll gain coverage of trailing arrays that would otherwise be ignored by FORTIFY and sanitize=bounds.

Easing fuzzing is a plus but not the initial purpose sanitizers: aim is to detect errors (memory, out-of-bounds, etc.)

Your distinction between CFI and stak proctection is not that separate. For instance the two stacks (safe and unsafe) are used for CFI insurance

Currently, for the GCC 12 and Clang 11 TL;DR, I don't see the control flow integrity flag mentioned on the detailed page... is this because it is Intel specific?
-fcf-protection=full

In some other references, I see recommendations to enable the following flag for Intel x86 as well:
-mshstk

Choose spelling between analyzer and analyser

Note by @Flameeyes on Twitter: https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/

Don't understand how the definition you give relies with the term "tautology" that refers to predicates that are always true

According to https://reviews.llvm.org/D64742 pattern zero works when used in conjunction with -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang (mandatory for C++, optional for C). Have you tried?

Strongly disagree with that statement: if you used early in the development phase (and not compiling the code with security flags just before going into production), the false positive rate should not be that high

C norm specifies that sizeof(long) >= sizeof(int). Note the ">=". I suggest to either remove your example or add "on architectures where sizeof(long) < sizeof(int)"

First of all, great work! Thanks for compiling all this very useful information :-)

Regarding clang's -fsanitize=integer option, the sanitizer might be a little picky when it comes to unsigned integers arithmetic and left shift operations. According to 6.2.5.9 of ISO C99, unsigned integers "can never overflow" (https://frama-c.com/download/frama-c-rte-manual.pdf), while the sanitizer will trigger a "runtime error" whenever a left shift on an unsigned integer will overflow a primitive unsigned integer type size or when an arithmetic operation does so. Nonetheless, such operations are quite common e.g. when developing big int or cryptographic libraries.

It might be useful to document the ways of deactivating explicitly such errors (especially if the integer sanitizer is used for production) while keeping the other undefined behaviors using -fno-sanitize=unsigned-integer-overflow -fno-sanitize=unsigned-shift-base.

Regards,

Link explaining the concept is broken but you can point directly on the research it is based on: https://dslab.epfl.ch/research/cpi/

"to be enabled to be effective" => "to be enabled"

rather "to mazimize the classes of detected errors"?