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: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat 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 15:31:03 +0000
- 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>
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?
> 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, 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)?
(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.)
--
Joseph S. Myers
joseph@codesourcery.com