[PATCH RFC] __builtin_dynamic_object_size with -D_FORTIFY_SOURCE=3

[Florian Weimer]

* Jakub Jelinek:

> On Mon, Nov 30, 2020 at 10:11:51AM +0100, Florian Weimer wrote:
>> > For example at the moment the simple case of memcpy, memmove,
>> > etc. where they're implemented with compiler builtins like
>> > __builtin___memcpy_chk, clang is able to generate compact code that
>> > passes the expression to __memcpy_chk or just generates a memcpy when
>> > possible.  In the non-builtin cases though, where the size evaluates
>> > to an expression, one may see patterns like:
>> >
>> > 	cmpq	$-1, %rbx
>> > 	je	.LBB0_2
>> > 	callq	fortified_chk
>> > 	jmp	.LBB0_3
>> > .LBB0_2:                                # %if.else
>> > 	callq	fortified
>> >
>> > since the compiler isn't smart enough yet to reduce that condition.
>> > This can be fixed (I'm working on that right now) in the simple case
>> > of a direct comparison and thus work for _FORTIFY_SOURCE=3, but it may
>> > be harder to evaluate for __builtin_dynamic_object_size in general
>> > where the comparison happens indirectly.  This is also why
>> > __builtin_dynamic_object_size isn't exactly a drop-in replacement for
>> > __builtin_object_size in all cases.
>> 
>> I think this should be fixed in the compiler, and the level 3 should be
>> dropped.  A compiler bug is not a good reason to change the external
>> interface, especially if it is just a performance bug.  The 2 vs 3
>> choice isn't something that's useful to developers.
>
> What bug do you mean?

The pointless run-time check to choose between the _chk and non-_chk
variants.

> The fact that __builtin_object_size is required to be a constant has
> been a fundamental requirement of the whole _FORTIFY_SOURCE design.
> Without that, it adds completely unbounded runtime overhead, turning
> the program ultimately into yet another bounded pointers
> implementation.  In the worst case, every pointer arithmetic will need
> to be accomodated by tracking of its runtime length, using
> maximum/minimum, saturated arithmetics etc.

Let's see if there is an actual performance impact for Clang.

I think it's wrong to view this in isolation.  Of course there will be
regressions for certain code sequences.  But glibc will use this in
conjunction with string functions, which already trigger heavy
optimization from GCC with lots of code duplication.

The Clang implementation, once fixed, will give us a way to experiment
with this.

Maybe some trade-offs are possible: Track just the end of the allocated
buffer, at the cost of some accuracy.  Then intermediate pointer
arithmetic does not have to be instrumented.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill