This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 0/3] Fix {recv,send}{m}msg standard compliance (BZ#16919)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Wed, 8 Jun 2016 17:18:55 -0300
- Subject: Re: [PATCH v4 0/3] Fix {recv,send}{m}msg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1459175641-12520-1-git-send-email-adhemerval dot zanella at linaro dot org> <9df3c0d2-6c5b-5394-7b03-cfdfec13026c at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1606081234260 dot 12640 at digraph dot polyomino dot org dot uk> <20160608155708 dot GJ5431 at vapier dot lan> <bc9c5b23-7fb0-e191-5bec-cc65642fbbeb at redhat dot com>
On 08/06/2016 16:45, Florian Weimer wrote:
> On 06/08/2016 05:57 PM, Mike Frysinger wrote:
>> On 08 Jun 2016 12:37, Joseph Myers wrote:
>>> On Wed, 8 Jun 2016, Florian Weimer wrote:
>>>> This patchset breaks various network emulation libraries because applications
>>>> use the new struct msghdr definition, yet dlsym (RTLD_NEXT, "recvmsg") picks
>>>> the compat implementation.
>>>
>>> That seems like bug 14932. I think dlsym should return the current
>>> version. See previous discussions Apr-Jun 2013.
>>
>> agreed
>
> Yes, it seems all of you are right.
>
> So what's the short-term way forward here?
>
> Remove the compat symbol and perform the additional zeroing unconditionally?
>
> Even in the long temr, I'm not sure if we can fix RTLD_NEXT if there is just one unversioned symbol interposing multiple versioned symbols. I simply don't see a way it can be done. The interposing library would need more information about what's going on (data which should already be available to audit modules).
>
> Thanks,
> Florian
>
>
This is the same issue in GCC BZ#71445 [1] comments and currently we can either
remove the compat symbol or make the interposition using symbol versions.
If we decide to to remove the compat symbol I believe the only change in
libsanitizer or any interpose library would to be just assume recvmsg to
follow POSIX struct definition (in libsanitizer case to check the internal
structure accesses using socklen_t instead of size_t).
If we decide to still continue to provide the compat symbol, a way to interpose
the calls would to add interpose versions. This has the drawback that the
interposed library would need to know the provided version for each symbols
and they might differ for each architecture. This is the path I am implementing
to fix libsanitizer.
I do not have a strong opinion if we should or not provide compat symbols for
these symbols. I see that to trigger the compat usage, the program would need
to send a lot of data (>2GB) on a single syscall, which I think is really
unlikely and I presume there is no real case usage. Not providing the
compat symbol also is the easier way to fix interpose libraries.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445