Alternative libio vtable hardening approach
Florian Weimer
fweimer@redhat.com
Fri Jun 3 11:06:00 GMT 2016
On 06/03/2016 11:57 AM, Pedro Alves wrote:
> On 06/03/2016 10:44 AM, Florian Weimer wrote:
>
>> This will need an additional substraction in the validation code because
>> there is no relocation to express the different between two pointers,
>> even though this value is a link-time constant. The statically sized
>> array makes the difference a constant, avoiding this problem.
>
> Is it a problem in practice?
Probably not. I looked at the mechanism, and there is a scary comment:
/* Make SYMBOL, which is in the text segment, an element of SET. */
#define text_set_element(set, symbol) _elf_set_element(set, symbol)
/* When building a shared library, make the set section writable,
because it will need to be relocated at run time anyway. */
# define _elf_set_element(set, symbol) \
static const void *__elf_set_##set##_element_##symbol##__ \
__attribute__ ((used, section (#set))) = &(symbol)
But this doesn't seem to be true in practice, the relevant section
appears to be read-only (also eu-readelf says it's subject to RELRO).
Do you know how this mechanism works? There's a sed construct in
Makerules for $(common-objpfx)shlib.lds. I assume it would need adjusting.
A const array of vtables somehow seems more robust than this (but we
need to get this right anyway because of the callback pointers in these
symbol sets).
>> (GCC currently does not perform this optimization for pointer
>> differences, but it's easy enough to do it manually.)
>
> I believe it would sort out the "static link now pulls
> everything" issue mentioned downthread, though.
Yes, I think it would.
I'll give it a try.
Thanks,
Florian
More information about the Libc-alpha
mailing list