libio vtable verification failures with multiple libcs

[Florian Weimer]

On 08/10/2016 05:47 PM, Mike Frysinger wrote:
> On 10 Aug 2016 16:19, Florian Weimer wrote:
>> This is just a heads-up that the Ruby test suite loads libc.so.6 with an
>> absolute path, bypassing AT_PLATFORM directories.  This can lead to
>> multiple libc.so.6 copies within the same process:
>>
>>    <https://bugzilla.redhat.com/show_bug.cgi?id=1361037#c17>
>>
>> There is a test case which creates a FILE * object using one libc and
>> passes it to fprintf in another libc, which fails vtable verification
>> because the vtable is not known to fprintf.  The dlmopen bypass for
>> verification does not kick in because dlmopen is not used.
>>
>> I don't think there is anything we should change on the glibc side as
>> far as libio is concerned.  Fortunately, this is just a Ruby test case
>> for the Fiddle FFI module.  Correct Fiddle use should be unaffected.
>>
>> (But I do wonder if we should detect that the libc.so.6 soname is loaded
>> a second time and fail.)
>
> seems like this scenario is not specific to libio ?  any struct that we
> use pointer mangling on can't be shared across instances right ?  a quick
> grep shows setjmp/longjmp would fail too.

The secret for the pointer guard is derived in a deterministic way from 
AT_RANDOM.  Both libcs will obtain the same AT_RANDOM value and end up 
with the same secret, and therefore are compatible.

Strange things will happen with malloc and free, though, because the 
main arena will exist twice.

_res is shared.  errno probably is not.  And so on.

Some of these issues resurface in a different guise (e.g. bug 19773), 
but I don't think we need to support them for two-copies-of-libc case 
(without dlmopen).

Florian