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