All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 1/1] net: ioctl: Use kernel memory on protocol ioctl callbacks
Date: Fri, 19 May 2023 15:39:03 +0000	[thread overview]
Message-ID: <ZGeYF+pp8Ukbo4p5@gmail.com> (raw)
In-Reply-To: <20230519135821.922326-2-leitao@debian.org>

On Fri, May 19, 2023 at 11:09:29AM -0400, Willem de Bruijn wrote:
> On Fri, May 19, 2023 at 9:59 AM Breno Leitao <leitao@debian.org> 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 -
> > sock_skprot_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 sock_skproto_ioctl_in{out}() will
> > copy the userspace input, and copy it back to kernel space.
> >
> > The wrapper that prepares the buffer and puts the buffer back to user is
> > sock_skprot_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the
> > callee now calls sock_skprot_ioctl().
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> Overall this looks great to me.

Thanks for the guidance and quick review!

> 
> Thanks for the detailed commit message that lists all exceptions, Bruno.
> 
> Since that is a limited well understood list, I'm not in favor of the
> suggestion to add an explicit length argument that then needs to be
> checked in each callee.
> 
> > +/* Copy 'size' bytes from userspace and return `size` back to userspace */
> > +int sock_skproto_ioctl_inout(struct sock *sk, unsigned int cmd,
> > +                            void __user *arg, size_t size)
> > +{
> > +       void *ptr;
> > +       int ret;
> > +
> > +       ptr = kmalloc(size, GFP_KERNEL);
> > +       if (!ptr)
> > +               return -ENOMEM;
> 
> > +/* A wrapper around sock ioctls, which copies the data from userspace
> > + * (depending on the protocol/ioctl), and copies back the result to userspace.
> > + * The main motivation for this function is to pass kernel memory to the
> > + * protocol ioctl callsback, instead of userspace memory.
> > + */
> > +int sock_skprot_ioctl(struct sock *sk, unsigned int cmd,
> > +                     void __user *arg)
> > +{
> > +#ifdef CONFIG_IP_MROUTE
> > +       if (!strcmp(sk->sk_prot->name, "RAW")) {
> 
> This must check both sk_family and sk_protocol. That is preferable
> over string match.
> 
> For these exception cases, instead of having sock_skproto_ioctl_inout
> dynamically allocate the struct, how about stack allocating them here
> and passing to the function?

Should I stack allocate all the 4 structures sock_skprot_ioctl and pass
them to sock_skproto_ioctl_inout() together with the size? (using the
original name to avoid confusion - will rename in V2)

I mean, writing something as:

int sock_skprot_ioctl(struct sock *sk, unsigned int cmd
                     void __user *arg`
{
	struct sioc_vif_req sioc_vif_req_arg;
	struct sioc_sg_req sioc_sg_req_arg;
	struct sioc_mif_req6 sioc_mif_req6_arg;
	struct sioc_sg_req6 sioc_sg_req6_arg;

	..

	if (!strcmp(sk->sk_prot->name, "RAW6")) {
        switch (cmd) {
               case SIOCGETMIFCNT_IN6:
                       return sock_skproto_ioctl_inout(sk, cmd,
                               arg, &sioc_mif_req6_arg, sizeof(sioc_mif_req6_arg);
               case SIOCGETSGCNT_IN6:
                       return sock_skproto_ioctl_inout(sk, cmd,
                               arg, &sioc_sg_req6_arg, sizeof(sioc_sg_req6_arg));
               }
       }
       ...
}

WARNING: multiple messages have this Message-ID (diff)
From: Breno Leitao <leitao@debian.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: axboe@kernel.dk, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, courmisch@gmail.com,
	nhorman@tuxdriver.com, asml.silence@gmail.com,
	alex.aring@gmail.com, dccp@vger.kernel.org,
	mptcp@lists.linux.dev, linux-kernel@vger.kernel.org,
	matthieu.baerts@tessares.net, marcelo.leitner@gmail.com,
	linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org,
	leit@fb.com, David.Laight@aculab.com, dsahern@kernel.org
Subject: Re: [PATCH 1/1] net: ioctl: Use kernel memory on protocol ioctl callbacks
Date: Fri, 19 May 2023 08:39:03 -0700	[thread overview]
Message-ID: <ZGeYF+pp8Ukbo4p5@gmail.com> (raw)
In-Reply-To: <CAF=yD-Jj6dvyOskL+F52_aaaCovVTcpoYSCeMY7xH=FK7r3Jiw@mail.gmail.com>

On Fri, May 19, 2023 at 11:09:29AM -0400, Willem de Bruijn wrote:
> On Fri, May 19, 2023 at 9:59 AM Breno Leitao <leitao@debian.org> 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 -
> > sock_skprot_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 sock_skproto_ioctl_in{out}() will
> > copy the userspace input, and copy it back to kernel space.
> >
> > The wrapper that prepares the buffer and puts the buffer back to user is
> > sock_skprot_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the
> > callee now calls sock_skprot_ioctl().
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> Overall this looks great to me.

Thanks for the guidance and quick review!

> 
> Thanks for the detailed commit message that lists all exceptions, Bruno.
> 
> Since that is a limited well understood list, I'm not in favor of the
> suggestion to add an explicit length argument that then needs to be
> checked in each callee.
> 
> > +/* Copy 'size' bytes from userspace and return `size` back to userspace */
> > +int sock_skproto_ioctl_inout(struct sock *sk, unsigned int cmd,
> > +                            void __user *arg, size_t size)
> > +{
> > +       void *ptr;
> > +       int ret;
> > +
> > +       ptr = kmalloc(size, GFP_KERNEL);
> > +       if (!ptr)
> > +               return -ENOMEM;
> 
> > +/* A wrapper around sock ioctls, which copies the data from userspace
> > + * (depending on the protocol/ioctl), and copies back the result to userspace.
> > + * The main motivation for this function is to pass kernel memory to the
> > + * protocol ioctl callsback, instead of userspace memory.
> > + */
> > +int sock_skprot_ioctl(struct sock *sk, unsigned int cmd,
> > +                     void __user *arg)
> > +{
> > +#ifdef CONFIG_IP_MROUTE
> > +       if (!strcmp(sk->sk_prot->name, "RAW")) {
> 
> This must check both sk_family and sk_protocol. That is preferable
> over string match.
> 
> For these exception cases, instead of having sock_skproto_ioctl_inout
> dynamically allocate the struct, how about stack allocating them here
> and passing to the function?

Should I stack allocate all the 4 structures sock_skprot_ioctl and pass
them to sock_skproto_ioctl_inout() together with the size? (using the
original name to avoid confusion - will rename in V2)

I mean, writing something as:

int sock_skprot_ioctl(struct sock *sk, unsigned int cmd
                     void __user *arg`
{
	struct sioc_vif_req sioc_vif_req_arg;
	struct sioc_sg_req sioc_sg_req_arg;
	struct sioc_mif_req6 sioc_mif_req6_arg;
	struct sioc_sg_req6 sioc_sg_req6_arg;

	..

	if (!strcmp(sk->sk_prot->name, "RAW6")) {
        switch (cmd) {
               case SIOCGETMIFCNT_IN6:
                       return sock_skproto_ioctl_inout(sk, cmd,
                               arg, &sioc_mif_req6_arg, sizeof(sioc_mif_req6_arg);
               case SIOCGETSGCNT_IN6:
                       return sock_skproto_ioctl_inout(sk, cmd,
                               arg, &sioc_sg_req6_arg, sizeof(sioc_sg_req6_arg));
               }
       }
       ...
}

  parent reply	other threads:[~2023-05-19 15:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19 13:58 [PATCH 1/1] net: ioctl: Use kernel memory on protocol ioctl callbacks Breno Leitao
2023-05-19 13:58 ` Breno Leitao
2023-05-19 14:22 ` David Laight
2023-05-19 14:22   ` David Laight
2023-05-19 15:09 ` Willem de Bruijn
2023-05-19 15:09   ` Willem de Bruijn
2023-05-19 15:25 ` net: ioctl: Use kernel memory on protocol ioctl callbacks: Tests Results MPTCP CI
2023-05-19 18:03   ` Mat Martineau
2023-05-22 11:17     ` Breno Leitao
2023-05-19 15:39 ` Breno Leitao [this message]
2023-05-19 15:39   ` [PATCH 1/1] net: ioctl: Use kernel memory on protocol ioctl callbacks Breno Leitao
2023-05-19 16:54 ` kernel test robot
2023-05-19 17:04 ` Willem de Bruijn
2023-05-19 17:04   ` Willem de Bruijn
2023-05-19 19:26 ` kernel test robot
2023-05-19 23:29 ` kernel test robot
2023-05-20  3:50 ` David Ahern
2023-05-20  3:50   ` David Ahern
2023-05-20 12:48 ` David Laight
2023-05-20 12:48   ` David Laight
2023-05-20 13:02 ` David Laight
2023-05-20 13:02   ` David Laight
  -- strict thread matches above, loose matches on Subject: below --
2023-05-19 13:58 [PATCH 0/1] net: ioctl: Use kernel buffer on proto " Breno Leitao
2023-05-19 13:58 ` Breno Leitao
2023-05-19 15:15 ` Jakub Kicinski
2023-05-19 15:15   ` Jakub Kicinski
2023-05-19 15:19 ` Breno Leitao
2023-05-19 15:19   ` Breno Leitao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZGeYF+pp8Ukbo4p5@gmail.com \
    --to=leitao@debian.org \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.