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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 62CE9C71156 for ; Mon, 30 Nov 2020 14:58:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F3C92206D8 for ; Mon, 30 Nov 2020 14:58:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZXbQY6t9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbgK3O6f (ORCPT ); Mon, 30 Nov 2020 09:58:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727781AbgK3O6e (ORCPT ); Mon, 30 Nov 2020 09:58:34 -0500 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A6E1C0613D3 for ; Mon, 30 Nov 2020 06:57:54 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id 64so16594088wra.11 for ; Mon, 30 Nov 2020 06:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ob/I2+lTNqu0iX3erLDSv6QM5dqJRM1YGvfiQ0Jm8Qc=; b=ZXbQY6t90VHTn/juSuMfIKzFlC3otTpTmsvpXbTTjzKSF6ph71eBWmEQgbD3+udT/8 LhuMg+TNLJbbe+eBuRbYIIcuIR3ofRyEQQcA0qGUEOtVvwestF2H+lo0pJpzkXPTXxjL LiB61fGX7ktfvIPUq42bRFbB290Zahi/khNwNpEJEx7OuslMXdMJk4QXRYMJqtIRd+Ph isSSDuh7lLT5a1TRwjJfs6n1a78ippOt7mAnM9lGEKM7N/pF6N9OoVXnwRJw92Fb05il zUZ8yqp5ehsslF/HFnOBR+zcgXa09SJNf6AlwxmWPPS1Bp02nB9h7HVv5vc1bd9Odz7g Mfsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ob/I2+lTNqu0iX3erLDSv6QM5dqJRM1YGvfiQ0Jm8Qc=; b=HeBLYHLU/kE0TfA+yXAts+eZxj5+P8Wnap8T3qdysuYZQW0vroUFevftajgaDGp0nL 7J6U6KO9UhMDHWwzdMjqVLiop75ulYL7V9jB8iub1zyMJMvoloS0H0bnDNRNgtRwcB9P JPrGPIzH2JkPxsZd/d9fjcA3WH/3SbSKu1SBQiHo1qwbeNRbnD6sv1zlHvKXNaxTIyCd vJX49O3eO+aEJ64Hv4O7TXdXka63sW69hYeqKwfhN7Ube1VjXLaYZ39pkSEFsHoKXoEG 2yOF73CQ/0KpG5pQUUm6k6IAmZAPlKoMDFugd48L02rd2dyVZISpf2MtFHT7o59Ct3SF VTjQ== X-Gm-Message-State: AOAM533istwSn1XjVXUIYpVCMDhlEb8RT5dyScajOsemHuta2DxEbb33 wZk1T7F7bOUIzKXe4JoRG9moTZmq5ZW/cTnnQ1yHVA== X-Google-Smtp-Source: ABdhPJzt4G/vo9Kb/nrgOBvOmMc5TWFK2TTilMyA2Wuy43CT4LLMuS+IWtwbsBRnAA3HO+a/V/Jy4AQWP87rKCEiISE= X-Received: by 2002:a5d:510d:: with SMTP id s13mr28528845wrt.380.1606748272375; Mon, 30 Nov 2020 06:57:52 -0800 (PST) MIME-Version: 1.0 References: <4bb2cb8a-c3ef-bfa9-7b04-cb2cca32d3ee@samba.org> <5d71d36c-0bfb-a313-07e8-0e22f7331a7a@samba.org> <12153e6a-37b1-872f-dd82-399e255eef5d@samba.org> In-Reply-To: <12153e6a-37b1-872f-dd82-399e255eef5d@samba.org> From: Soheil Hassas Yeganeh Date: Mon, 30 Nov 2020 09:57:16 -0500 Message-ID: Subject: Re: [RFC 0/1] whitelisting UDP GSO and GRO cmsgs To: Stefan Metzmacher Cc: Victor Stewart , io-uring , Luke Hsiao , "David S. Miller" , Jann Horn , Arjun Roy , netdev , Jens Axboe Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Mon, Nov 30, 2020 at 5:52 AM Stefan Metzmacher wrote: > > Am 28.11.20 um 20:03 schrieb Victor Stewart: > > On Thu, Nov 26, 2020 at 7:36 AM Stefan Metzmacher wrote: > >> > >> Am 23.11.20 um 17:29 schrieb Victor Stewart: > >>> On Mon, Nov 23, 2020 at 4:13 PM Stefan Metzmacher wrote: > >>>> > >>>> Hi Victor, > >>>> > >>>> wouldn't it be enough to port the PROTO_CMSG_DATA_ONLY check to the sendmsg path? > >>>> > >>>> UDP sockets should have PROTO_CMSG_DATA_ONLY set. > >>>> > >>>> I guess that would fix your current problem. > >>> > >>> that would definitely solve the problem and is the easiest solution. > >>> > >>> but PROTO_CMSG_DATA_ONLY is only set on inet_stream_ops and > >>> inet6_stream_ops but dgram? > >> > >> I guess PROTO_CMSG_DATA_ONLY should be added also for dgram sockets. > >> > >> Did you intend to remove the cc for the mailing list? > >> > >> I think in addition to the io-uring list, cc'ing netdev@vger.kernel.org > >> would also be good. > > > > whoops forgot to reply all. > > > > before I CC netdev, what does PROTO_CMSG_DATA_ONLY actually mean? > > I don't really know, but I guess it means that, any supported CMSG type > on that socket won't do any magic depending on the process state, like > fd passing with SOL_SOCKET/SCM_RIGHTS or SCM_CREDENTIALS. The CMSG buffer > would just be a plain byte array, which may only reference state attached > to the specific socket or packet. > > I'd guess that the author and/or reviewers can clarify that, let's see what > they'll answer. > > > I didn't find a clear explanation anywhere by searching the kernel, only > > that it was defined as 1 and flagged on inet_stream_ops and > > inet6_stream_ops. > > > > there must be a reason it was not initially included for dgrams? > > I can't think of any difference I guess the author just tried to get add support for the specific usecase > that didn't work (MSG_ZEROCOPY in this case, most likely only tested with a tcp workload): > > commit 583bbf0624dfd8fc45f1049be1d4980be59451ff > Author: Luke Hsiao > Date: Fri Aug 21 21:41:04 2020 -0700 > > io_uring: allow tcp ancillary data for __sys_recvmsg_sock() > > For TCP tx zero-copy, the kernel notifies the process of completions by > queuing completion notifications on the socket error queue. This patch > allows reading these notifications via recvmsg to support TCP tx > zero-copy. > > Ancillary data was originally disallowed due to privilege escalation > via io_uring's offloading of sendmsg() onto a kernel thread with kernel > credentials (https://crbug.com/project-zero/1975). So, we must ensure > that the socket type is one where the ancillary data types that are > delivered on recvmsg are plain data (no file descriptors or values that > are translated based on the identity of the calling process). Thank you for CCing us. The reason for PROTO_CMSG_DATA_ONLY is explained in the paragraph above in the commit message. PROTO_CMSG_DATA_ONLY is basically to allow-list a protocol that is guaranteed not to have the privilege escalation in https://crbug.com/project-zero/1975. TCP doesn't have that issue, and I believe UDP doesn't have that issue either (but please audit and confirm that with +Jann Horn). If you couldn't find any non-data CMSGs for UDP, you should just add PROTO_CMSG_DATA_ONLY to inet dgram sockets instead of introducing __sys_whitelisted_cmsghdrs as Stefan mentioned. Thanks, Soheil > This was tested by using io_uring to call recvmsg on the MSG_ERRQUEUE > with tx zero-copy enabled. Before this patch, we received -EINVALID from > this specific code path. After this patch, we could read tcp tx > zero-copy completion notifications from the MSG_ERRQUEUE. > > Signed-off-by: Soheil Hassas Yeganeh > Signed-off-by: Arjun Roy > Acked-by: Eric Dumazet > Reviewed-by: Jann Horn > Reviewed-by: Jens Axboe > Signed-off-by: Luke Hsiao > Signed-off-by: David S. Miller > > > but yes if there's nothing standing in the way of adding it for > > dgrams, and it covers UDP_SEGMENT and UDP_GRO then that's of course > > the least friction solution here. > > Yes, it would avoid whitelisting new specific usecases. > > metze > >