From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7633FC54EEB for ; Mon, 27 Apr 2020 20:08:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5986E206D6 for ; Mon, 27 Apr 2020 20:08:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="pPb/6Uyx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726791AbgD0UI3 (ORCPT ); Mon, 27 Apr 2020 16:08:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726641AbgD0UI3 (ORCPT ); Mon, 27 Apr 2020 16:08:29 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E236C0610D5 for ; Mon, 27 Apr 2020 13:08:29 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id h11so7385856plr.11 for ; Mon, 27 Apr 2020 13:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1ShJY97ZCiJN26A/m9Pl13+gxvYlJRi5H/MBiRQCKAA=; b=pPb/6UyxYym50tDXhyX1a2Dt0ycYdFDEFleuNy9likSHZM1YDH/Mwy/APDqV/HMClC Y99Jvj/GcprY0ku8mhhvp2uqwuEYkzr4P+OMwIYuchQEK7Z8Bm5iuR1+7WjAvYI9wqkx p6Li2CEx9EuPpX5CDgKzcqdBwU2ZB0dAoGSRUR0qe/GIWo10QkZ+AU0N/itvqQ1BEsAr I7FfxRXZ74oMcclJ2CTp77m4lrecsIOYhh7uhjl/vCUnEOtRS11RqVqDGkVmp4IOtsvg ktPmQqeCBRPFr3m9H9rH2Lr9OdV65yFCwef0lNvU6WDuOkWlfn/vtKHfFXD7y3HjYte2 RGyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1ShJY97ZCiJN26A/m9Pl13+gxvYlJRi5H/MBiRQCKAA=; b=YwkDUxhOk3MncoRbn+MiJ0IT5+2ZXWITYbmjhhSAi2hrDvvmmCDw7KQjayBS0B461E cthfSPQ6de5dU64cx/5c9cXPTfcCRU8uhsMn0AUWTU+7+lWjB0+xJpOfeoPK2989BVq2 Iqn5FD2FRgkPxKf8ysl7rYF7dH3RzAL4JKMvFnIQqsE1RygTXvK2VGkOQp7vyP8CaJag TyRIbYC+rWAaNX109sKcKx0SR2IqRFcovY4/v1918G+clf/ZZYQ9ox3MgDMChA+pcFTv /KwwWG8G5q7Qf2aC4Mj0kOnXPKnUngLoLQ8VnK5R2OHbK4D8cSEaA7P5flNzVE4AJokH qmVA== X-Gm-Message-State: AGi0PuYP1K7ecUYDxvVrOOdroujFpyYxYzrpGQgh9vYdxBEigIB9TWHi y7pgwHnQOJJUec9l2v0Imh+6Ew== X-Google-Smtp-Source: APiQypKcScA7Ko4tejh9itu5hKiarr5afUS+iaM7D2DRTjJkJ4oHtScMvoMG59upANfBpyoSmGb0HQ== X-Received: by 2002:a17:90b:8d7:: with SMTP id ds23mr432561pjb.39.1588018108641; Mon, 27 Apr 2020 13:08:28 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.145]) by smtp.gmail.com with ESMTPSA id g40sm113985pje.38.2020.04.27.13.08.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2020 13:08:28 -0700 (PDT) Subject: Re: io_uring, IORING_OP_RECVMSG and ancillary data To: Jann Horn Cc: Andreas Smas , linux-fsdevel , io-uring References: <45d7558a-d0c8-4d3f-c63a-33fd2fb073a5@kernel.dk> From: Jens Axboe Message-ID: <217dc782-161f-7aea-2d18-4e88526b8e1d@kernel.dk> Date: Mon, 27 Apr 2020 14:08:25 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 4/27/20 2:03 PM, Jann Horn wrote: > On Mon, Apr 27, 2020 at 9:53 PM Jens Axboe wrote: >> On 4/27/20 1:29 PM, Jens Axboe wrote: >>> On 4/27/20 1:20 PM, Jann Horn wrote: >>>> On Sat, Apr 25, 2020 at 10:23 PM Jens Axboe wrote: >>>>> On 4/25/20 11:29 AM, Andreas Smas wrote: >>>>>> Hi, >>>>>> >>>>>> Tried to use io_uring with OP_RECVMSG with ancillary buffers (for my >>>>>> particular use case I'm using SO_TIMESTAMP for incoming UDP packets). >>>>>> >>>>>> These submissions fail with EINVAL due to the check in __sys_recvmsg_sock(). >>>>>> >>>>>> The following hack fixes the problem for me and I get valid timestamps >>>>>> back. Not suggesting this is the real fix as I'm not sure what the >>>>>> implications of this is. >>>>>> >>>>>> Any insight into this would be much appreciated. >>>>> >>>>> It was originally disabled because of a security issue, but I do think >>>>> it's safe to enable again. >>>>> >>>>> Adding the io-uring list and Jann as well, leaving patch intact below. >>>>> >>>>>> diff --git a/net/socket.c b/net/socket.c >>>>>> index 2dd739fba866..689f41f4156e 100644 >>>>>> --- a/net/socket.c >>>>>> +++ b/net/socket.c >>>>>> @@ -2637,10 +2637,6 @@ long __sys_recvmsg_sock(struct socket *sock, >>>>>> struct msghdr *msg, >>>>>> struct user_msghdr __user *umsg, >>>>>> struct sockaddr __user *uaddr, unsigned int flags) >>>>>> { >>>>>> - /* disallow ancillary data requests from this path */ >>>>>> - if (msg->msg_control || msg->msg_controllen) >>>>>> - return -EINVAL; >>>>>> - >>>>>> return ____sys_recvmsg(sock, msg, umsg, uaddr, flags, 0); >>>>>> } >>>> >>>> I think that's hard to get right. In particular, unix domain sockets >>>> can currently pass file descriptors in control data - so you'd need to >>>> set the file_table flag for recvmsg and sendmsg. And I'm not sure >>>> whether, to make this robust, there should be a whitelist of types of >>>> control messages that are permitted to be used with io_uring, or >>>> something like that... >>>> >>>> I think of ancillary buffers as being kind of like ioctl handlers in >>>> this regard. >>> >>> Good point. I'll send out something that hopefully will be enough to >>> be useful, whole not allowing anything randomly. >> >> That things is a bit of a mess... How about something like this for >> starters? > [...] >> +static bool io_net_allow_cmsg(struct msghdr *msg) >> +{ >> + struct cmsghdr *cmsg; >> + >> + for_each_cmsghdr(cmsg, msg) { > > Isn't this going to dereference a userspace pointer? ->msg_control has > not been copied into the kernel at this point, right? Possibly... Totally untested, maybe I forgot to mention that :-) I'll check. The question was more "in principle" if this was a viable approach. The whole cmsg_type and cmsg_level is really a mess. -- Jens Axboe