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

[James Y Knight via cfe-dev]

Neither the docs nor the review seem to explain why this new
special-purpose "fortify-stdlib" attribute is necessary. Were you were
unaware that there's already an implementation of a fortified libc built on
existing clang features, or is that existing mechanism unsatisfactory?

If we _do_ need a new attribute for this for some reason, then having it
special-case a list of function names is quite unfortunate -- the list it
supports now certainly isn't the complete list of functions that need
fortified versions, and some of those functions which need fortified
versions in a given libc aren't defined by any standard. Having to add
support for them all into the compiler seems rather unsatisfactory.

So, if this new feature *is* needed for some reason, it would seem much
better to make the behavior explicitly specified in the attribute, rather
than special cased for a given set of known function-names. (E.g. the
attribute could specify exactly what edits to make to the function call:
which name to call instead, and what extra arguments to insert where into
the argument list.)

On Tue, Feb 19, 2019 at 7:02 PM Erik Pilkington <erik.pilkington at gmail.com>
wrote:

>
>
> On Feb 19, 2019, at 3:34 PM, Reid Kleckner via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> On Tue, Feb 19, 2019 at 3:15 PM James Y Knight <jyknight at google.com>
> wrote:
>
>> 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).
>>
>
> It is unfortunate, however, that the two communities haven't settled on an
> agreeable set of extensions to implement this feature. I can understand why
> glibc wouldn't want a second parallel implementation with it's own set of
> bugs requiring its own tests. Getting this right really requires someone
> who cares about it enough to get involved in all of the relevant projects
> here: glibc, clang, gcc, and maybe even bionic. That sounds like a lot of
> work, so I understand why it hasn't been done.
>
>
> I’ve been working on improving _FORTIFY_SOURCE support for apple’s c
> standard library. I added the attribute fortify_stdlib (
> https://clang.llvm.org/docs/AttributeReference.html#fortify-stdlib) so it
> should just be a matter of glibc slapping it on a few functions and clang
> will do the rest, which doesn’t seem like much of a burden. The narrative
> that clang is far behind GCC for _FORTIFY doesn’t really add up to me
> either, there are some clang extensions that GCC doesn’t support either,
> for instance: __builtin_dynamic_object_size and pass_object_size.
>
> _______________________________________________
> 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/bb307b1e/attachment.html>