[PATCH RFC] __builtin_dynamic_object_size with -D_FORTIFY_SOURCE=3
Jakub Jelinek
jakub@redhat.com
Mon Nov 30 10:31:56 GMT 2020
On Mon, Nov 30, 2020 at 11:10:56AM +0100, Florian Weimer wrote:
> 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.
There is no "the allocated buffer", a pointer may point to many different
ones and which ones depends on the control flow etc. and for each of the
allocations there could be different pointer arithmetics involved, in both
directions. As can be seen e.g. on following example, LLVM really does
implement it as bounded pointers, the sizes are then precise, but the
runtime cost is high. There is no limit it to simple most common cases.
typedef __SIZE_TYPE__ size_t;
void *malloc (size_t);
void free (void *);
int
foo (int p[128], int q)
{
char *r = malloc (q);
for (int i = 0; i < 64; i++)
{
if (p[i])
r += p[64 + i];
}
size_t ret = __builtin_dynamic_object_size (r, 0);
free (r);
return ret;
}
Actually, trying:
typedef __SIZE_TYPE__ size_t;
void *malloc (size_t);
void free (void *);
int
bar (int p[192], int q, char *s)
{
char *r = malloc (q);
for (int i = 0; i < 64; i++)
{
if (p[i])
r += p[64 + i];
if (p[128 + i])
r = s;
}
size_t ret = __builtin_dynamic_object_size (r, 0);
free (r);
return ret;
}
in that case LLVM gives up, so maybe it does the tracking only
if all the possible values have some known object size.
Even with the above foo test where r can have (expensively computed)
precise value, if one e.g. add char *s argument and uses
s ? s : r in __builtin_dynamic_object_size, it just returns -1.
Jakub
More information about the Libc-alpha
mailing list