[v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables

  Hi!

This is a resend (from 2011!) of my PTR_MANGLE series for the FILE vtable.
It was previously discussed here:
https://sourceware.org/ml/libc-alpha/2011-12/msg00073.html

It sounds like only very very old code was sharing FILE externally,
so this appears safe now. "make xcheck" passes. If this is NOT okay for
general use, I'd like to make it a configure option, since for modern
glibc users, it works fine. (e.g. Chrome OS has been using this patch
for 3 years now.)

Thanks!

-Kees

[v2: fixed GNU style, URL, thanks to vapier]
---
2015-08-12  Kees Cook <keescook@chromium.org>

	* libio/libioP.h: Create inline helpers to run the PTR_MANGLE and
	PTR_DEMANGLE routines on vtable pointers. Create _IO_JUMPS_SET and
	_IO_WIDE_JUMPS_SET macros to use the new inline helpers. Update the
	_IO_JUMPS_FUNC and _IO_WIDE_JUMPS_FUNC to use the new inline helpers.
	* debug/obprintf_chk.c: Replace direct vtable assignment with macro.
	* debug/vasprintf_chk.c: Likewise.
	* debug/vdprintf_chk.c: Likewise.
	* debug/vsnprintf_chk.c: Likewise.
	* debug/vsprintf_chk.c: Likewise.
	* libio/fileops.c: Likewise.
	* libio/freopen.c: Likewise.
	* libio/freopen64.c: Likewise.
	* libio/genops.c: Likewise.
	* libio/iofdopen.c: Likewise.
	* libio/iofopen.c: Likewise.
	* libio/iofopncook.c: Likewise.
	* libio/iofwide.c: Likewise.
	* libio/iopopen.c: Likewise.
	* libio/iovdprintf.c: Likewise.
	* libio/iovsprintf.c: Likewise.
	* libio/iovsscanf.c: Likewise.
	* libio/memstream.c: Likewise.
	* libio/obprintf.c: Likewise.
	* libio/oldiofdopen.c: Likewise.
	* libio/oldiofopen.c: Likewise.
	* libio/oldiopopen.c: Likewise.
	* libio/vasprintf.c: Likewise.
	* libio/vsnprintf.c: Likewise.
	* stdio-common/isoc99_vsscanf.c: Likewise.
	* stdio-common/vfprintf.c: Likewise.
	* stdlib/strfmon_l.c: Likewise.
	* misc/init-misc.c: Mangle predefined stdio FILE vtables at startup.
---
 debug/obprintf_chk.c          |  2 +-
 debug/vasprintf_chk.c         |  2 +-
 debug/vdprintf_chk.c          |  2 +-
 debug/vsnprintf_chk.c         |  2 +-
 debug/vsprintf_chk.c          |  2 +-
 libio/fileops.c               | 28 +++++++++----------
 libio/freopen.c               |  6 ++---
 libio/freopen64.c             |  4 +--
 libio/genops.c                |  2 +-
 libio/iofdopen.c              |  4 +--
 libio/iofopen.c               |  8 +++---
 libio/iofopncook.c            |  4 +--
 libio/iofwide.c               |  2 +-
 libio/iopopen.c               |  2 +-
 libio/iovdprintf.c            |  2 +-
 libio/iovsprintf.c            |  2 +-
 libio/iovsscanf.c             |  2 +-
 libio/libioP.h                | 62 ++++++++++++++++++++++++++++++-------------
 libio/memstream.c             |  2 +-
 libio/obprintf.c              |  2 +-
 libio/oldiofdopen.c           |  2 +-
 libio/oldiofopen.c            |  2 +-
 libio/oldiopopen.c            |  2 +-
 libio/vasprintf.c             |  2 +-
 libio/vsnprintf.c             |  2 +-
 misc/init-misc.c              | 13 +++++++++
 stdio-common/isoc99_vsscanf.c |  2 +-
 stdio-common/vfprintf.c       |  2 +-
 stdlib/strfmon_l.c            |  2 +-
 29 files changed, 104 insertions(+), 67 deletions(-)
  

On 10/01/2015 08:40 PM, Kees Cook wrote:
> Hi!
> 
> This is a resend (from 2011!) of my PTR_MANGLE series for the FILE vtable.
> It was previously discussed here:
> https://sourceware.org/ml/libc-alpha/2011-12/msg00073.html
> 
> It sounds like only very very old code was sharing FILE externally,
> so this appears safe now. "make xcheck" passes. If this is NOT okay for
> general use, I'd like to make it a configure option, since for modern
> glibc users, it works fine. (e.g. Chrome OS has been using this patch
> for 3 years now.)

This needs a configure option for now, but we can enable it for some
architectures per default.

At one point, someone needs to do the thankless job and unearth where
the cut-over point to modern libstdc++ was, and which architectures
actually need the vtable compatibility.  (If there was no GCC version
that could compile the relevant libstdc++ versions, then compatibility
is obviously unnecessary.)

Even better, if we can grab a few old binaries and they do not run on
current systems for other libstdc++-related reasons (or perhaps we
subtly broke the libio ABI over time), we might justify giving up
backwards compatibility in this area.
  

On Thu, Oct 1, 2015 at 11:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 10/01/2015 08:40 PM, Kees Cook wrote:
>> Hi!
>>
>> This is a resend (from 2011!) of my PTR_MANGLE series for the FILE vtable.
>> It was previously discussed here:
>> https://sourceware.org/ml/libc-alpha/2011-12/msg00073.html
>>
>> It sounds like only very very old code was sharing FILE externally,
>> so this appears safe now. "make xcheck" passes. If this is NOT okay for
>> general use, I'd like to make it a configure option, since for modern
>> glibc users, it works fine. (e.g. Chrome OS has been using this patch
>> for 3 years now.)
>
> This needs a configure option for now, but we can enable it for some
> architectures per default.

How do you think this should best be handled? (Are there examples of
similar configure flags?)

> At one point, someone needs to do the thankless job and unearth where
> the cut-over point to modern libstdc++ was, and which architectures
> actually need the vtable compatibility.  (If there was no GCC version
> that could compile the relevant libstdc++ versions, then compatibility
> is obviously unnecessary.)

Is there a hint about how to detect this? I don't know what I'd be looking for.

> Even better, if we can grab a few old binaries and they do not run on
> current systems for other libstdc++-related reasons (or perhaps we
> subtly broke the libio ABI over time), we might justify giving up
> backwards compatibility in this area.

I'm open to suggestions on what to test. :)

-Kees
  

On 10/01/2015 09:01 PM, Kees Cook wrote:
> On Thu, Oct 1, 2015 at 11:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 10/01/2015 08:40 PM, Kees Cook wrote:
>>> Hi!
>>>
>>> This is a resend (from 2011!) of my PTR_MANGLE series for the FILE vtable.
>>> It was previously discussed here:
>>> https://sourceware.org/ml/libc-alpha/2011-12/msg00073.html
>>>
>>> It sounds like only very very old code was sharing FILE externally,
>>> so this appears safe now. "make xcheck" passes. If this is NOT okay for
>>> general use, I'd like to make it a configure option, since for modern
>>> glibc users, it works fine. (e.g. Chrome OS has been using this patch
>>> for 3 years now.)
>>
>> This needs a configure option for now, but we can enable it for some
>> architectures per default.
> 
> How do you think this should best be handled? (Are there examples of
> similar configure flags?)

Probably something like this in configure.ac:

AC_ARG_ENABLE([stackguard-randomization],
              AC_HELP_STRING([--enable-stackguard-randomization],
                             [initialize __stack_chk_guard canary with a
random number at program start]),
              [enable_stackguard_randomize=$enableval],
              [enable_stackguard_randomize=no])
if test "$enable_stackguard_randomize" = yes; then
  AC_DEFINE(ENABLE_STACKGUARD_RANDOMIZE)
fi

And you need to update config.h.in.

>> At one point, someone needs to do the thankless job and unearth where
>> the cut-over point to modern libstdc++ was, and which architectures
>> actually need the vtable compatibility.  (If there was no GCC version
>> that could compile the relevant libstdc++ versions, then compatibility
>> is obviously unnecessary.)
> 
> Is there a hint about how to detect this? I don't know what I'd be looking for.

libio.h is apparently an installed header, so it is still part of the
public API.  This means that this API is technically supported on all
current architectures, even those which never saw the old libstdc++
version.  (libstdc++ switched in 2003…)

This means that vtable mangling is very much a backwards-incompatible
change.  We can still salvage this in some way.

Do you care mainly about statically linked libc, dynamically linked
libc, or both?
  

On Thu, Oct 1, 2015 at 12:31 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 10/01/2015 09:01 PM, Kees Cook wrote:
>> On Thu, Oct 1, 2015 at 11:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 10/01/2015 08:40 PM, Kees Cook wrote:
>>>> Hi!
>>>>
>>>> This is a resend (from 2011!) of my PTR_MANGLE series for the FILE vtable.
>>>> It was previously discussed here:
>>>> https://sourceware.org/ml/libc-alpha/2011-12/msg00073.html
>>>>
>>>> It sounds like only very very old code was sharing FILE externally,
>>>> so this appears safe now. "make xcheck" passes. If this is NOT okay for
>>>> general use, I'd like to make it a configure option, since for modern
>>>> glibc users, it works fine. (e.g. Chrome OS has been using this patch
>>>> for 3 years now.)
>>>
>>> This needs a configure option for now, but we can enable it for some
>>> architectures per default.
>>
>> How do you think this should best be handled? (Are there examples of
>> similar configure flags?)
>
> Probably something like this in configure.ac:
>
> AC_ARG_ENABLE([stackguard-randomization],
>               AC_HELP_STRING([--enable-stackguard-randomization],
>                              [initialize __stack_chk_guard canary with a
> random number at program start]),
>               [enable_stackguard_randomize=$enableval],
>               [enable_stackguard_randomize=no])
> if test "$enable_stackguard_randomize" = yes; then
>   AC_DEFINE(ENABLE_STACKGUARD_RANDOMIZE)
> fi
>
> And you need to update config.h.in.

Thanks! I'll poke around...

>
>>> At one point, someone needs to do the thankless job and unearth where
>>> the cut-over point to modern libstdc++ was, and which architectures
>>> actually need the vtable compatibility.  (If there was no GCC version
>>> that could compile the relevant libstdc++ versions, then compatibility
>>> is obviously unnecessary.)
>>
>> Is there a hint about how to detect this? I don't know what I'd be looking for.
>
> libio.h is apparently an installed header, so it is still part of the
> public API.  This means that this API is technically supported on all
> current architectures, even those which never saw the old libstdc++
> version.  (libstdc++ switched in 2003…)
>
> This means that vtable mangling is very much a backwards-incompatible
> change.  We can still salvage this in some way.

Well, no, I don't think that itself makes it backward-incompatible:
_IO_jump_t and _IO_FILE are opaque structures in libio.h. Am I missing
something?

> Do you care mainly about statically linked libc, dynamically linked
> libc, or both?

I care about both, but I tend to only use dynamic.

-Kees
  

On 10/01/2015 09:40 PM, Kees Cook wrote:

>>> How do you think this should best be handled? (Are there examples of
>>> similar configure flags?)
>>
>> Probably something like this in configure.ac:

>> And you need to update config.h.in.
> 
> Thanks! I'll poke around...

It's probably not needed if we come up with a completely
backwards-compatible approach.

>> libio.h is apparently an installed header, so it is still part of the
>> public API.  This means that this API is technically supported on all
>> current architectures, even those which never saw the old libstdc++
>> version.  (libstdc++ switched in 2003…)
>>
>> This means that vtable mangling is very much a backwards-incompatible
>> change.  We can still salvage this in some way.
> 
> Well, no, I don't think that itself makes it backward-incompatible:
> _IO_jump_t and _IO_FILE are opaque structures in libio.h. Am I missing
> something?

There is a full definition, and there is a widely-used getopt.c file
which references it (although not the vtable bits).  Let's hope it's not
actually unused. :-(

Functions like putc also use it.  Removing libio.h from the API likely
breaks the papi package.

>> Do you care mainly about statically linked libc, dynamically linked
>> libc, or both?
> 
> I care about both, but I tend to only use dynamic.

In the dynamic case, we compile in all the vtables we need.  We should
put them into an array, so that we can check easily if we have a
known-good vtable.  If we deprecate libio API (remove the installed
header and the default symbol version), we could set flag once we
encounter a reference to a libio symbol, and when that happens, we set a
flag that disables the vtable check.

The difficult question is how many symbol version bumps we need for this
to work.  Do we have to bump all stdio symbols, too, because someone
could write their own _IO_FILE class and pass it to fread?

Florian
  

On Thu, Oct 1, 2015 at 1:14 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 10/01/2015 09:40 PM, Kees Cook wrote:
>
>>>> How do you think this should best be handled? (Are there examples of
>>>> similar configure flags?)
>>>
>>> Probably something like this in configure.ac:
>
>>> And you need to update config.h.in.
>>
>> Thanks! I'll poke around...
>
> It's probably not needed if we come up with a completely
> backwards-compatible approach.
>
>>> libio.h is apparently an installed header, so it is still part of the
>>> public API.  This means that this API is technically supported on all
>>> current architectures, even those which never saw the old libstdc++
>>> version.  (libstdc++ switched in 2003…)
>>>
>>> This means that vtable mangling is very much a backwards-incompatible
>>> change.  We can still salvage this in some way.
>>
>> Well, no, I don't think that itself makes it backward-incompatible:
>> _IO_jump_t and _IO_FILE are opaque structures in libio.h. Am I missing
>> something?
>
> There is a full definition, and there is a widely-used getopt.c file
> which references it (although not the vtable bits).  Let's hope it's not
> actually unused. :-(

I can't find reference to the vtable portion of the structure outside
of the glibc sources.

> Functions like putc also use it.  Removing libio.h from the API likely
> breaks the papi package.
>
>>> Do you care mainly about statically linked libc, dynamically linked
>>> libc, or both?
>>
>> I care about both, but I tend to only use dynamic.
>
> In the dynamic case, we compile in all the vtables we need.  We should
> put them into an array, so that we can check easily if we have a
> known-good vtable.  If we deprecate libio API (remove the installed
> header and the default symbol version), we could set flag once we
> encounter a reference to a libio symbol, and when that happens, we set a
> flag that disables the vtable check.
>
> The difficult question is how many symbol version bumps we need for this
> to work.  Do we have to bump all stdio symbols, too, because someone
> could write their own _IO_FILE class and pass it to fread?

I can't find where it's possible to write one's own _IO_FILE class.

-Kees
  

On Thu, 1 Oct 2015, Florian Weimer wrote:

> >> At one point, someone needs to do the thankless job and unearth where
> >> the cut-over point to modern libstdc++ was, and which architectures
> >> actually need the vtable compatibility.  (If there was no GCC version
> >> that could compile the relevant libstdc++ versions, then compatibility
> >> is obviously unnecessary.)
> > 
> > Is there a hint about how to detect this? I don't know what I'd be looking for.
> 
> libio.h is apparently an installed header, so it is still part of the
> public API.  This means that this API is technically supported on all
> current architectures, even those which never saw the old libstdc++
> version.  (libstdc++ switched in 2003…)

I don't think it's part of the public API; it should only ever be included 
via <stdio.h>, and only the non-reserved-namespace <stdio.h> interfaces 
are part of the public API.  (Note that various _IO_* names may be used in 
<stdio.h> macros / inlines so may be part of the public ABI that way.)  By 
modern glibc standards, this header, and _G_config.h, should be entirely 
in bits/.

(It looks like, while it was GCC 3.4 that removed all traces of libio use, 
GCC 3.0 through 3.3 didn't actually default to using it in libstdc++-v3.  
I don't know if libstdc++ versions using libio actually did so in a way 
that embedded dependencies on vtable contents in the libstdc++ binaries or 
in executables using it.)
  

On Thu, 1 Oct 2015, Florian Weimer wrote:

> Even better, if we can grab a few old binaries and they do not run on
> current systems for other libstdc++-related reasons (or perhaps we

The libstdc++ SONAME changed in GCC 3.4, so any relevant binaries will be 
using an old libstdc++ shared library (or possibly statically linked with 
libstdc++ but dynamically linked with libc).
  

On Thu, Oct 1, 2015 at 2:00 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 1 Oct 2015, Florian Weimer wrote:
>
>> Even better, if we can grab a few old binaries and they do not run on
>> current systems for other libstdc++-related reasons (or perhaps we
>
> The libstdc++ SONAME changed in GCC 3.4, so any relevant binaries will be
> using an old libstdc++ shared library (or possibly statically linked with
> libstdc++ but dynamically linked with libc).

So system without ancient static binaries and no libstdc++-v3 or
earlier should be safe for this change? When did v4 happen? Seems like
a long time ago?

-Kees
  

On Thu, 1 Oct 2015, Kees Cook wrote:

> On Thu, Oct 1, 2015 at 2:00 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Thu, 1 Oct 2015, Florian Weimer wrote:
> >
> >> Even better, if we can grab a few old binaries and they do not run on
> >> current systems for other libstdc++-related reasons (or perhaps we
> >
> > The libstdc++ SONAME changed in GCC 3.4, so any relevant binaries will be
> > using an old libstdc++ shared library (or possibly statically linked with
> > libstdc++ but dynamically linked with libc).
> 
> So system without ancient static binaries and no libstdc++-v3 or
> earlier should be safe for this change? When did v4 happen? Seems like
> a long time ago?

It's still libstdc++-v3 even though it's gone through multiple SONAMEs 
(it's been v3 since GCC 3.0).  The question is libstdc++.so.5 or older - 
or dynamically linked binaries from compilers of that vintage with 
libstdc++.a linked in.
  

On Thu, Oct 1, 2015 at 2:41 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 1 Oct 2015, Kees Cook wrote:
>
>> On Thu, Oct 1, 2015 at 2:00 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> > On Thu, 1 Oct 2015, Florian Weimer wrote:
>> >
>> >> Even better, if we can grab a few old binaries and they do not run on
>> >> current systems for other libstdc++-related reasons (or perhaps we
>> >
>> > The libstdc++ SONAME changed in GCC 3.4, so any relevant binaries will be
>> > using an old libstdc++ shared library (or possibly statically linked with
>> > libstdc++ but dynamically linked with libc).
>>
>> So system without ancient static binaries and no libstdc++-v3 or
>> earlier should be safe for this change? When did v4 happen? Seems like
>> a long time ago?
>
> It's still libstdc++-v3 even though it's gone through multiple SONAMEs
> (it's been v3 since GCC 3.0).  The question is libstdc++.so.5 or older -
> or dynamically linked binaries from compilers of that vintage with
> libstdc++.a linked in.

Okay, so, since roughly 2007? Should I name the config "--only-v6+" or
something?

-Kees
  

On 01 Oct 2015 15:27, Kees Cook wrote:
> On Thu, Oct 1, 2015 at 2:41 PM, Joseph Myers wrote:
> > On Thu, 1 Oct 2015, Kees Cook wrote:
> >> On Thu, Oct 1, 2015 at 2:00 PM, Joseph Myers wrote:
> >> > On Thu, 1 Oct 2015, Florian Weimer wrote:
> >> >> Even better, if we can grab a few old binaries and they do not run on
> >> >> current systems for other libstdc++-related reasons (or perhaps we
> >> >
> >> > The libstdc++ SONAME changed in GCC 3.4, so any relevant binaries will be
> >> > using an old libstdc++ shared library (or possibly statically linked with
> >> > libstdc++ but dynamically linked with libc).
> >>
> >> So system without ancient static binaries and no libstdc++-v3 or
> >> earlier should be safe for this change? When did v4 happen? Seems like
> >> a long time ago?
> >
> > It's still libstdc++-v3 even though it's gone through multiple SONAMEs
> > (it's been v3 since GCC 3.0).  The question is libstdc++.so.5 or older -
> > or dynamically linked binaries from compilers of that vintage with
> > libstdc++.a linked in.
> 
> Okay, so, since roughly 2007? Should I name the config "--only-v6+" or
> something?

i wouldn't make it opaque.  just call it something like "libio-file-ptr-mangle".
then in the documentation, describe the possible limitations.
-mike
  

On 10/03/2015 12:22 AM, Mike Frysinger wrote:
> On 01 Oct 2015 15:27, Kees Cook wrote:
>> Okay, so, since roughly 2007? Should I name the config "--only-v6+" or
>> something?

It's more like 2003, but I need to double-check the dates.

> i wouldn't make it opaque.  just call it something like "libio-file-ptr-mangle".

It should be --disable-libio-compatibility or something like that.  If
we know all the possible vtables, we can do much better in terms of
hardening, and likely even devirtualize some of the function calls.
Pointer mangling is better than nothing, but I don't think the option
should be tied to that.

> then in the documentation, describe the possible limitations.

I plan to put the results of my libio archaeology on the wiki.  It
should make documenting the impact of the new configure option easier.

Florian
  

On 10/01/2015 10:28 PM, Kees Cook wrote:

>>>> libio.h is apparently an installed header, so it is still part of the
>>>> public API.  This means that this API is technically supported on all
>>>> current architectures, even those which never saw the old libstdc++
>>>> version.  (libstdc++ switched in 2003…)
>>>>
>>>> This means that vtable mangling is very much a backwards-incompatible
>>>> change.  We can still salvage this in some way.

> I can't find reference to the vtable portion of the structure outside
> of the glibc sources.

I tried to collect relevant information regarding this matter here,
while still keeping things relatively short:

  <https://sourceware.org/glibc/wiki/LibioVtables>

>> The difficult question is how many symbol version bumps we need for this
>> to work.  Do we have to bump all stdio symbols, too, because someone
>> could write their own _IO_FILE class and pass it to fread?
> 
> I can't find where it's possible to write one's own _IO_FILE class.

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?

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.

Initial internal feedback from Red Hat is that we do not need vtable
compatibility for libio.

Florian
  

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.)
  

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
  

On Thu, 15 Oct 2015, Florian Weimer wrote:

> > 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.

Well, I think the starting point is that those are valid binaries that 
users who've kept their binaries and libstdc++.so shared libraries should 
be able to expect to continue to work - that we don't break binary 
compatibility for users using documented interfaces in the documented way.

We have symbol versioning for backwards compatibility with binaries built 
with glibc 2.0.  Is it not possible to do something like that for 
compatibility with these C++ binaries (if necessary, increasing the value 
of _G_IO_IO_FILE_VERSION / _IO_stdin_used again)?

(I don't know how much compatibility the existing versioning provides if 
the executable and shared libraries mix binaries built with 2.0 and 
binaries built with >= 2.1.  If we introduce new versions I suppose we'd 
want mixtures of pre- and post-2.23 executables and shared libraries to 
work as long as they don't have any code using old libstdc++, but the old 
libstdc++ case could probably be limited to having the executable and all 
the non-glibc shared libraries it uses built with old glibc.  And 
architectures not supported before GCC 3.0 wouldn't need the compatibility 
code.)

> > (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.

Is that about 2.96 or backported architecture support (since 2.95.3 
doesn't have ports to those architectures at all)?
  

On 10/15/2015 05:56 PM, Joseph Myers wrote:
> On Thu, 15 Oct 2015, Florian Weimer wrote:
> 
>>> 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.
> 
> Well, I think the starting point is that those are valid binaries that 
> users who've kept their binaries and libstdc++.so shared libraries should 
> be able to expect to continue to work - that we don't break binary 
> compatibility for users using documented interfaces in the documented way.

I respect your view, but we did that for errno (and presumably _res and
h_errno, but I have less experience with that) and the i386 ABI bump for
SSE stack alignment.

> We have symbol versioning for backwards compatibility with binaries built 
> with glibc 2.0.  Is it not possible to do something like that for 
> compatibility with these C++ binaries (if necessary, increasing the value 
> of _G_IO_IO_FILE_VERSION / _IO_stdin_used again)?

If we can detect that a binary references these symbols:

_IO_file_init@GLIBC_2.1
_IO_init@GLIBC_2.0
_IO_str_init_readonly@GLIBC_2.0
_IO_str_init_static@GLIBC_2.0

we can disable vtable hardening globally.  This would not cover the
scenario where the binary dlopens something that uses an old libstdc++
(linked statically or dynamically) later, but it would provide
compatibility where a copy of libstdc++ is pulled in through DT_NEEDED.

This will not enable us to do substantial implementation changes in
libio because we would still be committed to the tight coupling with old
libstdc++, and we would have to keep maintaining two code paths
indefinitely (one of which is impossible to test without a historic
toolchain).

Bumping symbol versions for stdio functions would cause significant pain
for distributions which do not do mass rebuilds because FILE * streams
are often passed across library boundaries.

>>> (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.
> 
> Is that about 2.96 or backported architecture support (since 2.95.3 
> doesn't have ports to those architectures at all)?

ia64 seems to be 2.96, s390 and s390x are 2.95.

Florian
  

On Thu, 15 Oct 2015, Florian Weimer wrote:

> > Well, I think the starting point is that those are valid binaries that 
> > users who've kept their binaries and libstdc++.so shared libraries should 
> > be able to expect to continue to work - that we don't break binary 
> > compatibility for users using documented interfaces in the documented way.
> 
> I respect your view, but we did that for errno (and presumably _res and
> h_errno, but I have less experience with that) and the i386 ABI bump for
> SSE stack alignment.

As I said, starting point.  The basic presumption is against breaking any 
valid binaries; sometimes it may be rebutted, but that needs a compelling 
case to justify the breakage.

In the SSE stack alignment case I think we ought to be realigning the 
stack on entry to glibc at entry points that existed long enough ago and 
where SSE is used in a way that requires 16-byte alignment, as I said in 
<https://sourceware.org/ml/libc-alpha/2013-08/msg00372.html>.

It would, admittedly, be convenient if we could do the occasional global 
ABI transition with SONAME bump to limit how long compatibility is needed 
with problematic old ABIs - we've had libc.so.6 a lot longer than 
GNU/Linux had either libc.so.4 or libc.so.5.  But given how it seems to 
have been concluded that's not practical for libstdc++ I suppose it's not 
practical for libc either (on some architectures - the ARM move to EABI 
went fine).
  

On 10/15/2015 06:16 PM, Florian Weimer wrote:
> If we can detect that a binary references these symbols:
> 
> _IO_file_init@GLIBC_2.1
> _IO_init@GLIBC_2.0
> _IO_str_init_readonly@GLIBC_2.0
> _IO_str_init_static@GLIBC_2.0
> 
> we can disable vtable hardening globally.  This would not cover the
> scenario where the binary dlopens something that uses an old libstdc++
> (linked statically or dynamically) later, but it would provide
> compatibility where a copy of libstdc++ is pulled in through DT_NEEDED.

This just occurred to me:

If we use the array-of-vtables approach I mentioned earlier (a range
check on the vtable pointer, as opposed to PTR_MANGLE/PTR_DEMANGLE), we
could enable that until one of the functions list above is called.  As a
result, we would have both vtable hardening *and* full backwards
compatibility.

We just need a safe way to store the flag and reset it if needed (see
the previous thread, “Encoding page size in the ELF header” :-).  For a
start, we could simply use a global variable.

And the change adds more than one instruction, we should benchmark a few
functions like fread_unlocked or fflush_unlocked to see if it has
measurable impact.

Florian