[llvm-dev] [cfe-dev] clang and -D_FORTIFY_SOURCE=1

[George Burgess IV via llvm-dev]

FWIW, there's an existing implementation of a unified gcc+clang FORTIFY on
top of glibc 2.27:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/sys-libs/glibc/files/local/glibc-2.27-clang-fortify.patch
. For the reasons James mentioned, this needs a hefty amount of macro
magic, and there're always going to be discrepancies in what GCC catches vs
what Clang catches(*).

Upstream glibc was generally receptive to the changes when I proposed them
a while back, but I haven't found the time to push it through. I'm more
than happy to help as I can if someone wants to pick that up and run with
it.

(*) - especially in the realm of compiler diags, and as we need to inline N
callers and are expecting -D_FORTIFY_SOURCE=2-level accuracy. Happy to
elaborate if it'd be helpful.

On Tue, Dec 3, 2019 at 12:02 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The glibc implementation of FORTIFY_SOURCE is indeed not compatible with
> clang, because it uses compiler extensions which were trivial to implement
> in GCC's architecture, but difficult/impossible in clang's.
>
> However, clang does provide other mechanisms by which the same results can
> be achieved.
>
> If anyone is interested in glibc fully supporting fortify mode with clang,
> way to achieve this would be to look at the implementation in the bionic
> libc's headers, and then implement the same technique in glibc.
>
> On Tue, Dec 3, 2019 at 2:48 PM Martin Storsjö via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Tue, 3 Dec 2019, Serge Guelton via cfe-dev wrote:
>>
>> > 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.
>>
>> I remember looking at the fortify macros recently, and iirc the issue was
>> that the __builtin_object_size builtin, when used in an inline function,
>> can't evaluate the size of the object in the context where it is inlined,
>> which the glibc fortify macros/inline functions depend on.
>>
>> This has been discussed before, e.g. here:
>> http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html
>>
>> // Martin
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/a7622325/attachment.html>