This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Kees Cook <keescook at chromium dot org>, libc-alpha <libc-alpha at sourceware dot org>, Mike Frysinger <vapier at gentoo dot org>, Adam Conrad <adconrad at 0c3 dot net>
- Date: Thu, 15 Oct 2015 17:37:37 +0200
- Subject: Re: [PATCH v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables
- Authentication-results: sourceware.org; auth=none
- References: <20151001184048 dot GA31563 at www dot outflux dot net> <560D8108 dot 6060802 at redhat dot com> <CAGXu5jLi7iW+543YD7ySDb7Yq+_2SfGW8q3z50p4C3Usg5dC0w at mail dot gmail dot com> <560D8A2F dot 8020900 at redhat dot com> <CAGXu5jLCBUKaXoX3Dy1dcEc9bd0WcXAZU32zOaEHXechEfNuxg at mail dot gmail dot com> <560D943C dot 40301 at redhat dot com> <CAGXu5jKNssVif3=JsufU0a_tQpcURVgdDjDdHUkRmY1PQdv7LQ at mail dot gmail dot com> <561FA2CA dot 1050309 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1510151523160 dot 32402 at digraph dot polyomino dot org dot uk>
On 10/15/2015 05:31 PM, Joseph Myers wrote:
> On Thu, 15 Oct 2015, Florian Weimer wrote:
>
>> The key point is that in GCC 2.95, you could introduce additional
>> vtables by deriving from std::streambuf (or std::filebuf and the other
>> classes).
>>
>> I think we should proceed with some form of vtable hardening. I think
>> the main choice we face is:
>>
>> Do we want backwards compatibility with binaries which use
>> custom vtables with glibc's libio?
>
> Does that mean only binaries that passed such derived classes directly to
> glibc functions, not any binaries that simply made use of standard C++
> features?
All binaries which used the old libio-based libstdc++ would be affected.
>> If the answer is ânoâ, I suggest we apply Kees' patch *and* remove the
>> libio symbols listed only in <libioP.h> (technically an ABI break), so
>> that affected applications break in a well-defined way, instead of
>> crashing with a segmentation fault.
>
> Would that still keep working (a) C++ binaries, whether using shared or
> static libstdc++, built with any official GCC release supporting glibc2,
> where those binaries did not pass C++ classes to C interfaces,
No, they would no longer work.
> and (b) C
> binaries built against any glibc version (i.e. none of the libioP.h
> interfaces have ever been used through stdio.h interfaces in glibc 2.0 or
> later, and none are used by old libstdc++.so)?
Yes, for libioP.h (the private, non-installed header). We may have
overlooked something, and code which uses <libio.h> directly may be
affected by changes (certainly if we proceed to clean up things and
devirtualize some of the functions). But it has been suggested on this
thread that struct _IO_FILE is internal (along with the support
functions in <libio.h>) although it is an installed header file.
> (I'm not concerned with binaries built with non-default configurations of
> GCC 3.0 or later, which restricts compatibility concerns to architectures
> supported in 2.95 with ABIs still supported in glibc. I think that means
> alpha, i386 32-bit, m68k, mips 32-bit, powerpc 32-bit, sparc 32-bit and
> 64-bit.)
We have libstdc++ compat libraries for ia64, s390 and s390x, too.
Florian