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

[James Y Knight via cfe-dev]

Whoops, I also meant to include a link in that last email:
https://android.googlesource.com/platform/bionic/+/11dff3e91c6afd68e4e6c46f8249d10f07f307a7/libc/include/bits/fortify/stdio.h#75

(Note, the key here is the "pass_object_size" attribute, which allows
__builtin_object_size work on an argument to a _non_-inlined function).

On Tue, Feb 19, 2019 at 10:36 PM James Y Knight <jyknight at google.com> wrote:

> 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/6b9bdca9/attachment.html>