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

[James Y Knight via cfe-dev]

On Tue, Feb 19, 2019 at 5:22 PM Reid Kleckner via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>

Exactly -- _FORTIFY_SOURCE is a *libc* feature, not a clang feature. Here
we're talking about the implementation in glibc -- which was developed for
GCC, and nobody in the glibc community has yet been bothered to implement
proper support in clang.

But I'm fairly sure that Clang _does have_ all of the functionality
necessary to implement all of the fortifications enabled by
_FORTIFY_SOURCE=2 in glibc, because it has been implemented in Bionic libc
-- using an entirely different set of compiler extensions which are
supported only in Clang.

If someone wishes to contribute support to glibc to better support these
fortifications with clang, it should be pretty easy. Simply look at how
FORTIFY_SOURCE is implemented in the Bionic libc, and do something similar
to that (with appropriate ifdeffery, because that version is not going to
work in GCC).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190219/5eaadb70/attachment.html>