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: Kees Cook <keescook at chromium dot org>
- Cc: 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 14:57:46 +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>
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