This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]