Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp4370451rwd; Tue, 23 May 2023 06:59:20 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ70uUAeCFQdEb8wYgPoikAGHQ1WwyEBRsOPbZlTXSt/xb1z85LsWKW/PDgOvtSLMLKxfIoG X-Received: by 2002:a05:6a00:99c:b0:63d:5de3:b3f2 with SMTP id u28-20020a056a00099c00b0063d5de3b3f2mr20160023pfg.18.1684850360386; Tue, 23 May 2023 06:59:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684850360; cv=none; d=google.com; s=arc-20160816; b=FoStyK75hwylLesTYFzUfXcAO0zif7iOdYVdgE3DCD+mVJsEWzkQQz8zYys1/W22aa w59nsRO97DmxnQL5pRUfXV5Za3PmS7tZtgbldpxNT7/MJnDtyRbr/pwPeJL+OxA2tX6j QaCse2JOq/HWqe19+d0D3lTnV5C32GSd7yrrBlR6ZiURQjsoBKE+IIhBiPfIe4JeNefb CPk3+KwGtCHqBToaf/nwUZ0lpSQiunmH9p0855DJoFc2xtwrUhSKzWOMnIckjP2pKTKV hn1ITMzCfbgfhC6/jCqeSJ33oNzqZLVDWculIJBTNcbb0r4MASq5ObF5i145UBlYUduU ZYFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1mc3JRJZXPFyTZ68DrWTJks/5tRPJ+X1/0qnu16j9u0=; b=e6hNkQGYQDFjmX+tXKfo3wnHZ4CEHNnU//tufkyoBm7mepxfL50cNeDaA83Hi4IJeR I4z5cJFdDK0QF7PQmPqEFZ9lBCTwbECDsl0pbE5IBZhNGF8+JqekejDbmT85uh/9XnsS yXphS3FIeoXR4RCyEir2t0C49MkDhHUGeGSNBAi7VDQ2/jdXnE3HkukwFPmSb6bnVv65 cg0ax6XOpEFiHXyEiXnudKc6nW0LxvRNHhwDWoyMx2gRnYQ5bHPuwEVoU5GY391mzaIG PAT0WdCkC0x3GyGtNtiH/yOIeAqw6lxoj+wAQqKd+cG2BsLMhicAgUWlACHITQ+7Wl1x r/DQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e127-20020a636985000000b005347ed33099si2988246pgc.863.2023.05.23.06.59.07; Tue, 23 May 2023 06:59:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237064AbjEWNy5 (ORCPT + 99 others); Tue, 23 May 2023 09:54:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237104AbjEWNys (ORCPT ); Tue, 23 May 2023 09:54:48 -0400 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94B9DE56; Tue, 23 May 2023 06:54:25 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3f607dc98cdso14080365e9.1; Tue, 23 May 2023 06:54:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684850064; x=1687442064; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1mc3JRJZXPFyTZ68DrWTJks/5tRPJ+X1/0qnu16j9u0=; b=ePpON6/4uFLrwOdodpNKjfCPYSYlAbys8ZZ9+B172iKliZwEGmw2wzozD5zmEnn+k2 FT2WpCQGqOj+ojUe240pOd425x3Ss49/GnhYgr3lwd9WJnTuzXDmOYUPvJozYSG/CyzY rXmWWFJWQkqvTywTnCAVZ/0YMuwTU3DXQfH/CaBjctL1SOxLck06X0/888F/7of6KJRh axYpozX+vN3h9gLIrBCz1Ck9oLQNbeVpUtX59EjYs+Fjyvkraokg789ApnK1g101JxdC U0d4tOJfgDgLxqS6rQe0RDGC042Lrf0lSMF956X4zvV8Pq30BhBDzJUJ+X2gElsRHE/g d88A== X-Gm-Message-State: AC+VfDw7LuSmJYwI++ZsCYXrwKT0SpypIeeDeADZ/BI2fqe+ypxsERYv jtvbB4UtbDl4czT0Q5GRHag= X-Received: by 2002:a7b:cd8a:0:b0:3f6:a66:a372 with SMTP id y10-20020a7bcd8a000000b003f60a66a372mr1890685wmj.1.1684850063779; Tue, 23 May 2023 06:54:23 -0700 (PDT) Received: from gmail.com (fwdproxy-cln-012.fbsv.net. [2a03:2880:31ff:c::face:b00c]) by smtp.gmail.com with ESMTPSA id o5-20020a05600c378500b003f42314832fsm11741715wmr.18.2023.05.23.06.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 06:54:23 -0700 (PDT) Date: Tue, 23 May 2023 06:54:21 -0700 From: Breno Leitao To: Willem de Bruijn Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexander Aring , Stefan Schmidt , Miquel Raynal , David Ahern , Matthieu Baerts , Mat Martineau , Remi Denis-Courmont , Marcelo Ricardo Leitner , Xin Long , leit@fb.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, dccp@vger.kernel.org, linux-wpan@vger.kernel.org, mptcp@lists.linux.dev, linux-sctp@vger.kernel.org Subject: Re: [PATCH v2] net: ioctl: Use kernel memory on protocol ioctl callbacks Message-ID: References: <20230522134735.2810070-1-leitao@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 22, 2023 at 03:26:55PM -0400, Willem de Bruijn wrote: > On Mon, May 22, 2023 at 9:51 AM Breno Leitao wrote: > > > > Most of the ioctls to net protocols operates directly on userspace > > argument (arg). Usually doing get_user()/put_user() directly in the > > ioctl callback. This is not flexible, because it is hard to reuse these > > functions without passing userspace buffers. > > > > Change the "struct proto" ioctls to avoid touching userspace memory and > > operate on kernel buffers, i.e., all protocol's ioctl callbacks is > > adapted to operate on a kernel memory other than on userspace (so, no > > more {put,get}_user() and friends being called in the ioctl callback). > > > > This changes the "struct proto" ioctl format in the following way: > > > > int (*ioctl)(struct sock *sk, int cmd, > > - unsigned long arg); > > + int *karg); > > > > So, the "karg" argument, which is passed to the ioctl callback, is a > > pointer allocated to kernel space memory (inside a function wrapper - > > sk_ioctl()). This buffer (karg) may contain input argument > > (copied from userspace in a prep function) and it might return a > > value/buffer, which is copied back to userspace if necessary. There is > > not one-size-fits-all format (that is I am using 'may' above), but > > basically, there are three type of ioctls: > > > > 1) Do not read from userspace, returns a result to userspace > > 2) Read an input parameter from userspace, and does not return anything > > to userspace > > 3) Read an input from userspace, and return a buffer to userspace. > > > > The default case (1) (where no input parameter is given, and an "int" is > > returned to userspace) encompasses more than 90% of the cases, but there > > are two other exceptions. Here is a list of exceptions: > > > > * Protocol RAW: > > * cmd = SIOCGETVIFCNT: > > * input and output = struct sioc_vif_req > > * cmd = SIOCGETSGCNT > > * input and output = struct sioc_sg_req > > * Explanation: for the SIOCGETVIFCNT case, userspace passes the input > > argument, which is struct sioc_vif_req. Then the callback populates > > the struct, which is copied back to userspace. > > > > * Protocol RAW6: > > * cmd = SIOCGETMIFCNT_IN6 > > * input and output = struct sioc_mif_req6 > > * cmd = SIOCGETSGCNT_IN6 > > * input and output = struct sioc_sg_req6 > > > > * Protocol PHONET: > > * cmd == SIOCPNADDRESOURCE | SIOCPNDELRESOURCE > > * input int (4 bytes) > > * Nothing is copied back to userspace. > > > > For the exception cases, functions sk_ioctl_in{out}() will > > copy the userspace input, and copy it back to kernel space. > > > > The wrapper that prepare the buffer and put the buffer back to user is > > sk_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the > > callee now calls sk_ioctl(), which will handle all cases. > > > > Signed-off-by: Breno Leitao > > Going forward, please mark patches for net-next with [PATCH net-next v2] > > > --- a/include/net/udp.h > > +++ b/include/net/udp.h > > @@ -283,7 +283,7 @@ void udp_flush_pending_frames(struct sock *sk); > > int udp_cmsg_send(struct sock *sk, struct msghdr *msg, u16 *gso_size); > > void udp4_hwcsum(struct sk_buff *skb, __be32 src, __be32 dst); > > int udp_rcv(struct sk_buff *skb); > > -int udp_ioctl(struct sock *sk, int cmd, unsigned long arg); > > +int udp_ioctl(struct sock *sk, int cmd, int *karg); > > int udp_init_sock(struct sock *sk); > > int udp_pre_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len); > > int __udp_disconnect(struct sock *sk, int flags); > > diff --git a/net/core/sock.c b/net/core/sock.c > > index 5440e67bcfe3..a2cea95aec99 100644 > > --- a/net/core/sock.c > > +++ b/net/core/sock.c > > @@ -114,6 +114,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > This is for the ioctl constants only, right. Right. > Then like those header files, include the uapi header, and only that, > to minimize the dependencies added to net/core/sock.c ack! > > > #include > > > > @@ -138,6 +140,7 @@ > > > > #include > > #include > > +#include > > > > #include > > > > @@ -4106,3 +4109,112 @@ int sock_bind_add(struct sock *sk, struct sockaddr *addr, int addr_len) > > return sk->sk_prot->bind_add(sk, addr, addr_len); > > } > > EXPORT_SYMBOL(sock_bind_add); > > + > > +#ifdef CONFIG_PHONET > > +/* Copy u32 value from userspace and do not return anything back */ > > +static int sk_ioctl_in(struct sock *sk, unsigned int cmd, void __user *arg) > > The pointer can be const. > > > +{ > > + int karg; > > + > > + if (get_user(karg, (u32 __user *)arg)) > > + return -EFAULT; > > The comment and cast are u32, but the datatype is int. Is there a > reason for that. I just copied what we have in pn_ioctl()[1] static int pn_ioctl(struct sock *sk, int cmd, unsigned long arg) { switch (cmd) { case SIOCPNADDRESOURCE: case SIOCPNDELRESOURCE: { u32 res; if (get_user(res, (u32 __user *)arg)) .... I will cast it to "int" on V3. [1] https://github.com/torvalds/linux/blob/ae8373a5add4ea39f032563cf12a02946d1e3546/net/phonet/datagram.c#L47