This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/4] Fix {recv,send}{m}msg standard compliance (BZ#16919)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 21 Mar 2016 18:24:10 -0300
- Subject: Re: [PATCH 0/4] Fix {recv,send}{m}msg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1458592867-3057-1-git-send-email-adhemerval dot zanella at linaro dot org>
On 21-03-2016 17:41, Adhemerval Zanella wrote:
> This is an attempt of fixing the BZ#16919, recvmsg standard compliance,
> where Linux and POSIX differs in the msghdr and mmsghdr internal struct
> sizes. The issue is POSIX defines [1] both msghdr.msg_namelen,
> msghdr.controllen, and cmsghdr.cmsg_len as socklen_t, where Linux uses
> size_t. So for 64-bits architectures where size_t is larger sockelen_t
> it leads to standard inconsistence. Linux also added recvmmsg and
> sendmmsg, which uses a composite struct based on msghdr (mmsghdr).
>
> As stated in comment 6 at bugzilla report, both recvmsg and recvmmsg
> uses the msghdr structures which lie in memory that's (by the interface
> contract) writable by the function, so the adjustment is just to patch
> with zero the padding memebers. However sendmmsg's msghdr points to
> an already-filled control buffer containing cmsghdr structures that
> is not writable by the function's contract.
>
> So the proposed solutions follow four patches:
>
> 1. Add architecture specific socket.h header: splits the Linux
> socket.h definition in a platform specific one for the new
> msghdr and cmsghdr defition. The is just a functional change
> to lay the required headers (more rationale where it is not
> possible to support only on header on the patch comments).
>
> 2. Adjust kernel-features.h for sendmmsg/recvmmsg: this try to
> simplify the sendmmsg/recvmmsg __ASSUME definition and also
> fixes some x86 bugs when building using old kernel definitions.
>
> 3. network: recvmsg and sendmsg standard compliance: this is the
> first patch of the BZ#16919 fix where it handle both recvmsg
> and sendmsg.
>
> 4. network: recvmmsg and sendmmsg standard compliance: the second
> patch where is handles both recvmmsg and sendmmsg.
>
> This current solutions have some open spots that I would like to
> discuss:
>
> 1. Current sendmsg fix does not handle larger msg_control neither
> pads the cmsghdr associated. The problem with this approach
> is to accomplish a complete fix it will require to allocate
> a limited buffer, copying the incoming struct and zero pad.
> Although it tend to work it also add some limitation of total
> msg_control length.
> The general usage for such facily is passing file descriptors
> and permissions between processes over unix sockets so it might
> be factible to use a large stack allocated buffer (1024, 2048
> or large) and return ENOMEM for larger buffers.
>
> 2. Current approach adds symbol versioning for older implementation
> which uses the syscall directly. This is the default GLIBC
> policy for such changes, whoever I am not sure if there is any
> realword application that might break with this new implementation.
> So one option could get rid of the compatbility symbols.
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/
Something that I forgot to add:
3. Most of the complication on both recvmsg and sendmsg implementation
is because GLIBC still sets for x86 and x86_64 2.6.32 as the minimum
required kernel. Moving forward to 3.2 will allows up to remove
a lot of compatibility code (the stubs parts for instance).