From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40232 invoked by alias); 7 Apr 2016 12:23:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 40218 invoked by uid 89); 7 Apr 2016 12:23:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=07042016, Szabolcs, szabolcs, Nagy X-HELO: mail-yw0-f172.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Cx1GvsVeAuWJtC7meTBESIGdH9ncaS7ZAHSHlpWg3W8=; b=NnXIzoYbqiEfUbXsUwUMT1ews7ZlBxd26nAdEfJFdplKPmC27F1PK5ZmIEKx+xSe4h 6BBtLz66q11j2KBzWmvnxDwYUIRDOcF5igDUxCNHHtwlGtob+7bO2KzeDd2JgTn3N+O0 oJxBGlNXN/O+wFeP8SSTAbIm5fSfRv61y2MrbMhDGDBNfxVXegZT6E+0Dba2B9Af4lAV o1XVk3bq+Pl1VsnrS30Z+/ro9GOZH+eGQUpzK60DSOFJgi+PG8qgT35XjYYYCMKMNoR4 W8078b6i5wFZk4YruidS2c0764iD7zjafGdPdgRfwjjKWpsBfQ+sSwygQS2+z3sHbfF2 ilAg== X-Gm-Message-State: AD7BkJIRs+xDIG9ec0Or+bOTK/lLoqHlkuC07oohLdpJktYEDDia106Wh0sWR4kohfiC0acB X-Received: by 10.37.59.140 with SMTP id i134mr1303425yba.35.1460031802238; Thu, 07 Apr 2016 05:23:22 -0700 (PDT) Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919) To: Szabolcs Nagy , libc-alpha@sourceware.org References: <1459175641-12520-1-git-send-email-adhemerval.zanella@linaro.org> <1459175641-12520-3-git-send-email-adhemerval.zanella@linaro.org> <570626C4.2000305@arm.com> Cc: nd@arm.com From: Adhemerval Zanella Message-ID: <57065137.6040309@linaro.org> Date: Thu, 07 Apr 2016 12:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570626C4.2000305@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00101.txt.bz2 On 07-04-2016 06:22, Szabolcs Nagy wrote: > On 28/03/16 15:34, Adhemerval Zanella wrote: >> POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen >> to be of size int and socklen_t respectively. However Linux defines it as >> both size_t and for 64-bit it requires some adjustments to make the >> functions standard compliance. >> >> This patch fixes it by creating a temporary header and zeroing the pad >> fields for 64-bits architecture where size of size_t exceeds the size of >> the int. > > sendmsg is harder to fix because cmsghdr also needs fix ups: > >> /* Structure used for storage of ancillary data object information. */ >> struct cmsghdr >> { >> - size_t cmsg_len; /* Length of data in cmsg_data plus length >> - of cmsghdr structure. >> - !! The type should be socklen_t but the >> - definition of the kernel is incompatible >> - with this. */ >> +#if __BYTE_ORDER == __BIG_ENDIAN >> + int __glibc_reserved1; /* Pad toadjust Linux size to POSIX defined >> + size for cmsg_len. */ >> + socklen_t cmsg_len; /* Length of data in cmsg_data plus length >> + of cmsghdr structure. */ >> +#else >> + socklen_t cmsg_len; >> + int __glibc_reserved1; >> +#endif >> int cmsg_level; /* Originating protocol. */ >> int cmsg_type; /* Protocol specific type. */ > ... > >> ssize_t >> __libc_sendmsg (int fd, const struct msghdr *msg, int flags) >> { >> + /* POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen >> + to be int and socklen_t respectively. However Linux defines it as >> + both size_t. So for 64-bit it requires some adjustments by copying to >> + temporary header and zeroing the pad fields. */ >> +#if __WORDSIZE == 64 >> + struct msghdr hdr; >> + if (msg != NULL) >> + { >> + hdr = *msg; >> + hdr.__glibc_reserved1 = 0; >> + hdr.__glibc_reserved2 = 0; >> + msg = &hdr; >> + } >> +#endif > > e.g. user supplied msg.msg_control might contain cmsghdr > with __glibc_reserved1 != 0 since user code might not > initialize the struct. > > in musl this is fixed by copying the controls to a tmp > buf on the stack (which has fixed size so it can fail) > and fixing the paddings there. > Yes I am aware and I noted this in my patch header: 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. I am planning to send a fix for this based on this patch.