[llvm-dev] clang and -D_FORTIFY_SOURCE=1
Serge Guelton via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 3 02:07:15 PST 2019
Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic),
As a follow-up to that old thread about -D_FORTIFY_SOURCE=n
http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html
And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE
support is claimed to be only partial:
https://pagure.io/fesco/issue/2020
I dig into the glibc headers in order to have a better understanding of what's
going on, and wrote my notes here:
https://sergesanspaille.fedorapeople.org/fortify_source_requirements.rst
TL;DR: clang does provide a similar compile-time checking as gcc, but no runtime
checking. To assert that I wrote a small test suite:
https://github.com/serge-sans-paille/fortify-test-suite
And indeed, clang doesn't pass it, mostly because it turns call to
__builtin__(.*)_chk into calls to __builtin__\1.
We need to support the runtime behavior of the following builtins:
- __builtin___memcpy_chk
- __builtin___memmove_chk
- __builtin___mempcpy_chk
- __builtin___memset_chk
- __builtin___snprintf_chk
- __builtin___sprintf_chk
- __builtin___stpcpy_chk
- __builtin___strcat_chk
- __builtin___strcpy_chk
- __builtin___strncat_chk
- __builtin___strncpy_chk
- __builtin___vsnprintf_chk
- __builtin___vsprintf_chk
And I'd like to implement them at clang level, leveraging their existing
implementation. Is that the right way to go / any comments / issue with that
approach ?
More information about the llvm-dev
mailing list