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

-- 
Kees Cook
Chrome OS Security


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