[cfe-dev] How clang compares with gcc on security hardening ?

Reid Kleckner via cfe-dev cfe-dev at lists.llvm.org
Tue Feb 19 14:22:02 PST 2019


My (possibly not fully informed) understanding of the situation is
basically what this commenter said:
https://pagure.io/fesco/issue/2020#comment-545782
> (llvm doesn't implement e.g. _D_FORTIFY_SOURCE=2 properly)

As a clang developer, the way I see the issue is that -D_FORTIFY_SOURCE=2
liberally uses GCC extensions. Many changes could be made upstream in glibc
to make fortify source work better with clang. Implementing the extensions
needed in clang is a bit heroic.

I just want to push back on the narrative that we "haven't implemented"
_FORTIFY_SOURCE. Clang hasn't implemented some collection of
hard-to-implement GCC extensions, and
_FORTIFY_SOURCE happens to depend on them. Many of these extensions are
borderline incompatible with fundamental LLVM and Clang design decisions
(__builtin_va_arg_pack_len, see
https://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet),
and relaxing them isn't fun or easy. Many contributors are busy doing other
security related things, see all the work on shadow call stack, CFI,
speculative load hardening, sanitizers, coverage directed fuzzing, etc.

I also don't think there is clear consensus that _FORTIFY_SOURCE is a
valuable mitigation for most codebases. In C++ code, data is in vectors and
strings, not stack allocated arrays. It's not immediately clear that
_FORTIFY_SOURCE helps with this kind of code. So, for many contributors, it
is much lower priority than hardening virtual and indirect calls (CFI).

Regarding security, I don't think it's a clear cut case that one compiler
is "better". The user needs to be able to assess the inherent value of the
security mitigations provided by the compiler, and right now the compilers
just have different strengths, weaknesses, and depth of integration.

> and as mentioned above debuginfo issues.

This is a real problem, unfortunately, and it's been fairly well documented
in presentations, blog posts, etc. However, I subscribe to the debuginfo
project on Phabricator, and I regularly see reviews go by to do the work
necessary to improve variable location tracking, so hopefully things will
get better.

On Tue, Feb 19, 2019 at 11:43 AM Sylvestre Ledru via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hello,
>
> Looking at a Fedora thread ( https://pagure.io/fesco/issue/2020 ) about
> changing the compiler from gcc to clang to build Firefox,
> I noticed the following statement:
>
> "Clang lags significantly behind GCC on security hardening"
>
> Some of the arguments or missing features are discussed here:
>
> https://pagure.io/fesco/issue/2020#comment-546825 and other answers
> https://pagure.io/fesco/issue/2020#comment-545776
>
> I am wondering if these statements are accurate and if they are enough of
> a worry?
>
> Thanks,
> Sylvestre
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190219/28ac6022/attachment.html>


More information about the cfe-dev mailing list