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

[Florian Weimer <fweimer at redhat dot com>]

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