Re: Alternative libio vtable hardening approach

[Florian Weimer <fweimer at redhat dot com>]

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