[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