Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp666430rwd; Wed, 7 Jun 2023 05:29:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5hCg8LiHr0QMMujue7xJ5+cKRYmSZX7nKanufjdrKHC66Nj788uPVr+o1HBtQ4s0rjp1gc X-Received: by 2002:a05:6a00:16d1:b0:64f:ad7c:70fb with SMTP id l17-20020a056a0016d100b0064fad7c70fbmr5904919pfc.17.1686140960821; Wed, 07 Jun 2023 05:29:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686140960; cv=none; d=google.com; s=arc-20160816; b=zUj5y6S/DYwwX/sEZYPyv+ety6HweRjoOFPV4rVWScvwusSv51oMkSZQAP/uyizfa8 3oM2xjwF9fhpHuihFOoh0OkQS2yMWKS+d67SqjPsw6NND5CKroABkiUmGA3BMQNMNixs NYi1tzzZDL89JDlMcdrMuG8UoMlny8J/CQjdCOtfTFHbyABiA1uuis+r69OzNDJH8Xcn jiC//7OfHu0QWYlrag673emccZlYGt7ThbSjDhQ7MdsiIBECXwrUTeAkKtutqneVi1BA 9zTAx2o2DjcUJEzzGN7Bzhi1R6ngv0JNWP5wxkEkcxxZEttXDN5L122B2eOQLt2zZUev mIZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:dkim-signature; bh=u8XZPPmOXy+covKv0eQSNPQLMzOY+EavY6mLoP79rZc=; b=MvWqF9YOkWseS2BFAsQKYKUdU/ZfUkG4pmY6ZG4U7TREWtA3Y1jFLJle93hkWkrENP 9CwDGUY6N39rvz591LmC08GRBxINUGPRQa4wBZkRDPc2a/tiYYplrPadY89xYEqUB5hS lBEYfvkVlzii3rLsvleeB0qLQ45CjgDJEICY02XvujwGlkdNSjWzbG/WS9wu9WAWkJDu xAdTSieEj/xXN2397KntI2eHz4JjHzdZmhLpL+KCylD6YdRhwGEAsbWWbJbc4pK/VyGK UEiBoRdQE4NFzEhTzQ+KQmSyGs5woZN5+ZAV7wSD4bH65KP10D+kJ8TrBGMJnnu5dU/D Crpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=RGQvr3p0; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z123-20020a626581000000b00660d2553147si2302861pfb.212.2023.06.07.05.29.05; Wed, 07 Jun 2023 05:29: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; dkim=pass header.i=@gmail.com header.s=20221208 header.b=RGQvr3p0; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239921AbjFGMPg (ORCPT + 99 others); Wed, 7 Jun 2023 08:15:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239884AbjFGMPd (ORCPT ); Wed, 7 Jun 2023 08:15:33 -0400 Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0B3C1BD6; Wed, 7 Jun 2023 05:15:31 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-626157a186bso2335226d6.1; Wed, 07 Jun 2023 05:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686140131; x=1688732131; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=u8XZPPmOXy+covKv0eQSNPQLMzOY+EavY6mLoP79rZc=; b=RGQvr3p04xUWWIeDw2dJD14fHUEH+t2fQJULdyu1HiFLPmDI93BCxfeKaEMR6OzRbd 2WdXR6a5p62AeHvJvwoV1ag5/VvKU+reaumHWcxfGhuRRQrpkLx+EUKwC9srrIxu445f /AZ9jWJXl4MnmsS/bFhQbMOmnD8X2eUfGQzORHyDA6I5697PukxVm6Xmbud0o0CAxHK9 JfXOAKYktCDvSWwqUgzrd/jtv+e9Ed6IQcXReyd+np1mX+awYFT7eDnCIFt0s3vb740y FSpTAzbTFF/jMXT3fcdJMStR4lwyafdpb0sOXTsAQEDI4VventjDj0eUBgHwXMVS0Agg sxQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686140131; x=1688732131; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=u8XZPPmOXy+covKv0eQSNPQLMzOY+EavY6mLoP79rZc=; b=Cvn5iXqrWDQsWKrPXmUZrsj7Hf/8jtKDTpcqGeNXr0h/BBnXWtVS1Dq0pwcYWOR5ES 2aJBr9h9VLWaUN9v6X+MYGuhdZOAMhnq7ODIBaVJ84Lq+NTTw09F4Moz8U4PlLRKXWCG ZeWRJjUEiL5VOLxtqcXuq5mNBjKXWVYxe8FCkXsHu+lnfYoVx0r6SZoKN1VdVBPDQ88T 6idpLBG2guzpCgypnyjwZC+pjdS7r+VcG+zSpuff58MdUxkX8uPG2zdq4BA0of2UzSUT +6RCPEtzxhOsW3hBgjJ/G7sbleekRlJf7MWP8CDSnZL+OjWfDRjxcSkVxQy+HHnLCK0L WDKQ== X-Gm-Message-State: AC+VfDyJhiVQKwo8eXgiEXAZayEEsIJ/9kA5CnmF3b/CpoSQibkY1TmF Bu2McYJMwDpAGr3yLWgcUFw= X-Received: by 2002:a05:6214:518b:b0:621:65de:f600 with SMTP id kl11-20020a056214518b00b0062165def600mr3011629qvb.1.1686140130585; Wed, 07 Jun 2023 05:15:30 -0700 (PDT) Received: from localhost (172.174.245.35.bc.googleusercontent.com. [35.245.174.172]) by smtp.gmail.com with ESMTPSA id bz5-20020ad44c05000000b005f227de6b1bsm6029533qvb.116.2023.06.07.05.15.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 05:15:29 -0700 (PDT) Date: Wed, 07 Jun 2023 08:15:28 -0400 From: Willem de Bruijn To: Breno Leitao , Remi Denis-Courmont , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexander Aring , Stefan Schmidt , Miquel Raynal , David Ahern , Willem de Bruijn , Matthieu Baerts , Mat Martineau , Marcelo Ricardo Leitner , Xin Long Cc: axboe@kernel.dk, asml.silence@gmail.com, leit@fb.com, Martin KaFai Lau , Alexei Starovoitov , Kuniyuki Iwashima , Jason Xing , Joanne Koong , Hangyu Hua , Guillaume Nault , Andrea Righi , Wojciech Drewek , linux-kernel@vger.kernel.org (open list), netdev@vger.kernel.org (open list:NETWORKING [GENERAL]), dccp@vger.kernel.org (open list:DCCP PROTOCOL), linux-wpan@vger.kernel.org (open list:IEEE 802.15.4 SUBSYSTEM), mptcp@lists.linux.dev (open list:NETWORKING [MPTCP]), linux-sctp@vger.kernel.org (open list:SCTP PROTOCOL) Message-ID: <648074e0e52d9_143118294e0@willemb.c.googlers.com.notmuch> In-Reply-To: <20230606180045.827659-1-leitao@debian.org> References: <20230606180045.827659-1-leitao@debian.org> Subject: RE: [PATCH net-next v6] net: ioctl: Use kernel memory on protocol ioctl callbacks Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 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); > > (Important to say that this patch does not touch the "struct proto_ops" > protocols) > > So, the "karg" argument, which is passed to the ioctl callback, is a > pointer allocated to kernel space memory (inside a function wrapper). > 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 sock_sk_ioctl_inout() 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 Reviewed-by: Willem de Bruijn