public inbox for [email protected]
 help / color / mirror / Atom feed
From: Breno Leitao <[email protected]>
To: Willem de Bruijn <[email protected]>
Cc: [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected]
Subject: Re: [PATCH 2/4] io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT
Date: Tue, 25 Jul 2023 02:51:42 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Mon, Jul 24, 2023 at 06:58:04PM -0400, Willem de Bruijn wrote:
> Breno Leitao wrote:
> > Add support for getsockopt command (SOCKET_URING_OP_GETSOCKOPT), where
> > level is SOL_SOCKET. This is leveraging the sockptr_t infrastructure,
> > where a sockptr_t is either userspace or kernel space, and handled as
> > such.
> > 
> > Function io_uring_cmd_getsockopt() is inspired by __sys_getsockopt().
> > 
> > Differently from the getsockopt(2), the optlen field is not a userspace
> > pointers. In getsockopt(2), userspace provides optlen pointer, which is
> > overwritten by the kernel.  In this implementation, userspace passes a
> > u32, and the new value is returned in cqe->res. I.e., optlen is not a
> > pointer.
> > 
> > Important to say that userspace needs to keep the pointer alive until
> > the CQE is completed.
> > 
> > Signed-off-by: Breno Leitao <[email protected]>
> > ---
> >  include/uapi/linux/io_uring.h |  7 ++++++
> >  io_uring/uring_cmd.c          | 43 +++++++++++++++++++++++++++++++++++
> >  2 files changed, 50 insertions(+)
> > 
> > diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> > index 9fc7195f25df..8152151080db 100644
> > --- a/include/uapi/linux/io_uring.h
> > +++ b/include/uapi/linux/io_uring.h
> > @@ -43,6 +43,10 @@ struct io_uring_sqe {
> >  	union {
> >  		__u64	addr;	/* pointer to buffer or iovecs */
> >  		__u64	splice_off_in;
> > +		struct {
> > +			__u32	level;
> > +			__u32	optname;
> > +		};
> >  	};
> >  	__u32	len;		/* buffer size or number of iovecs */
> >  	union {
> > @@ -79,6 +83,7 @@ struct io_uring_sqe {
> >  	union {
> >  		__s32	splice_fd_in;
> >  		__u32	file_index;
> > +		__u32	optlen;
> >  		struct {
> >  			__u16	addr_len;
> >  			__u16	__pad3[1];
> > @@ -89,6 +94,7 @@ struct io_uring_sqe {
> >  			__u64	addr3;
> >  			__u64	__pad2[1];
> >  		};
> > +		__u64	optval;
> >  		/*
> >  		 * If the ring is initialized with IORING_SETUP_SQE128, then
> >  		 * this field is used for 80 bytes of arbitrary command data
> > @@ -729,6 +735,7 @@ struct io_uring_recvmsg_out {
> >  enum {
> >  	SOCKET_URING_OP_SIOCINQ		= 0,
> >  	SOCKET_URING_OP_SIOCOUTQ,
> > +	SOCKET_URING_OP_GETSOCKOPT,
> >  };
> >  
> >  #ifdef __cplusplus
> > diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c
> > index 8e7a03c1b20e..16c857cbf3b0 100644
> > --- a/io_uring/uring_cmd.c
> > +++ b/io_uring/uring_cmd.c
> > @@ -166,6 +166,47 @@ int io_uring_cmd_import_fixed(u64 ubuf, unsigned long len, int rw,
> >  }
> >  EXPORT_SYMBOL_GPL(io_uring_cmd_import_fixed);
> >  
> > +static inline int io_uring_cmd_getsockopt(struct socket *sock,
> > +					  struct io_uring_cmd *cmd)
> > +{
> > +	void __user *optval = u64_to_user_ptr(READ_ONCE(cmd->sqe->optval));
> > +	int optname = READ_ONCE(cmd->sqe->optname);
> > +	int optlen = READ_ONCE(cmd->sqe->optlen);
> > +	int level = READ_ONCE(cmd->sqe->level);
> > +	void *koptval;
> > +	int err;
> > +
> > +	err = security_socket_getsockopt(sock, level, optname);
> > +	if (err)
> > +		return err;
> > +
> > +	koptval = kmalloc(optlen, GFP_KERNEL);
> > +	if (!koptval)
> > +		return -ENOMEM;
> 
> This will try to kmalloc any length that userspace passes?

Yes, this value is coming directly from userspace.

> That is unnecessary ..
> > +
> > +	err = copy_from_user(koptval, optval, optlen);
> > +	if (err)
> > +		goto fail;
> > +
> > +	err = -EOPNOTSUPP;
> > +	if (level == SOL_SOCKET) {
> > +		err = sk_getsockopt(sock->sk, level, optname,
> > +				    KERNEL_SOCKPTR(koptval),
> > +				    KERNEL_SOCKPTR(&optlen));
> 
> .. sk_getsockopt defines a union of acceptable fields, which
> are all fairly small.

Right, and they are all I need for SOL_SOCKET level for now.

> I notice that BPF added BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN to
> work around the issue of pre-allocating for the worst case.

I am having a hard time how to understand how
BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN gets the MAX_OPTLEN. Reading this
function, it seems it is conditionally get_user().


	#define BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN(optlen)
	({
		int __ret = 0;
		if (cgroup_bpf_enabled(CGROUP_GETSOCKOPT))
			get_user(__ret, optlen);
		__ret;
	})

That said, how is BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN being used to
workaroundthe pre-allocating for the worst case?

> But that also needs to deal woth other getsockopt levels.

Right, and we also have a similar kmalloc() on the setsockopt path
(SOCKET_URING_OP_SETSOCKOPT).

What about if I pass the userspace sockptr (USER_SOCKPTR) to the
{g,s}etsockopt callback directly, instead of kmalloc() in io_uring(), as
I was doing int the RFC[1]? It avoids any extra kmalloc at all.

Something as:

	static inline int io_uring_cmd_getsockopt(struct socket *sock,
						  struct io_uring_cmd *cmd)
	{
		void __user *optval = u64_to_user_ptr(READ_ONCE(cmd->sqe->optval));
		int optlen = READ_ONCE(cmd->sqe->optlen);
		int optname = READ_ONCE(cmd->sqe->optname);
		int level = READ_ONCE(cmd->sqe->level);
		int err;

		err = security_socket_getsockopt(sock, level, optname);
		if (err)
			return err;

		if (level == SOL_SOCKET) {
			err = sk_getsockopt(sock->sk, level, optname,
					    USER_SOCKPTR(optval),
					    KERNEL_SOCKPTR(&optlen));
			if (err < 0)
				return err;
			return optlen;
		}

		return -EOPNOTSUPP;

Thanks for the review!

[1] Link: https://lore.kernel.org/all/[email protected]/

  reply	other threads:[~2023-07-25  9:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24 14:22 [PATCH 0/3] io_uring: Initial support for {s,g}etsockopt commands Breno Leitao
2023-07-24 14:22 ` [PATCH 1/4] net: expose sock_use_custom_sol_socket Breno Leitao
2023-07-24 14:22 ` [PATCH 2/4] io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT Breno Leitao
2023-07-24 17:31   ` Stanislav Fomichev
2023-07-25  9:27     ` Breno Leitao
2023-07-25 17:02       ` Stanislav Fomichev
2023-07-25 17:56         ` Martin KaFai Lau
2023-07-26  9:26           ` Breno Leitao
2023-07-28 17:03         ` Breno Leitao
2023-07-28 18:07           ` Stanislav Fomichev
2023-07-31 10:13             ` Breno Leitao
2023-07-24 22:58   ` Willem de Bruijn
2023-07-25  9:51     ` Breno Leitao [this message]
2023-07-25 13:56       ` Willem de Bruijn
2023-07-25 15:23         ` Breno Leitao
2023-07-24 14:22 ` [PATCH 3/4] io_uring/cmd: Introduce SOCKET_URING_OP_SETSOCKOPT Breno Leitao
2023-07-24 14:22 ` [PATCH 4/4] io_uring/cmd: Extend support beyond SOL_SOCKET 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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox