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 0/4] Fix {recv,send}{m}msg standard compliance (BZ#16919)



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


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