From: Willem de Bruijn <[email protected]>
To: Breno Leitao <[email protected]>,
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 09:56:50 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
Breno Leitao wrote:
> 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.
That looks like a great solution to me.
Avoids the whole problem of kmalloc based on untrusted user input.
> 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;
> }
Do you have a plan to extend this to other levels?
No need to implement immediately, but it would be good to know
whether it is feasible to extend the current solution when the
need (inevitably) shows up.
>
> return -EOPNOTSUPP;
>
> Thanks for the review!
>
> [1] Link: https://lore.kernel.org/all/[email protected]/
next prev parent reply other threads:[~2023-07-25 13:57 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
2023-07-25 13:56 ` Willem de Bruijn [this message]
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 \
--in-reply-to=64bfd4a27a1fe_3dc9bb2944e@willemb.c.googlers.com.notmuch \
[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