This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Alternative libio vtable hardening approach
- From: Florian Weimer <fweimer at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Kees Cook <keescook at chromium dot org>, Yunlian Jiang <yunlian at google dot com>
- Date: Fri, 3 Jun 2016 13:05:56 +0200
- Subject: Re: Alternative libio vtable hardening approach
- Authentication-results: sourceware.org; auth=none
- References: <b34105f2-adcb-9347-73c0-43079729c418 at redhat dot com> <ec8e25c2-d6b4-c372-6b81-5240cb973910 at redhat dot com> <a1a71129-c432-bfb4-8580-dcb79573c92e at redhat dot com> <c61f7050-b159-9bee-fc7c-47ccaf2f9e32 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