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, 1 Oct 2015 22:14:52 +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>
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