All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@google.com>
To: Kui-Feng Lee <sinquersw@gmail.com>
Cc: thinker.li@gmail.com, bpf@vger.kernel.org, ast@kernel.org,
	 martin.lau@linux.dev, song@kernel.org, kernel-team@meta.com,
	 andrii@kernel.org, yonghong.song@linux.dev, kuifeng@meta.com
Subject: Re: [RFC bpf-next v2 4/6] bpf: Provide bpf_copy_from_user() and bpf_copy_to_user().
Date: Mon, 14 Aug 2023 10:07:24 -0700	[thread overview]
Message-ID: <ZNpfTBh4cC1oW8Cf@google.com> (raw)
In-Reply-To: <0164ca41-01bc-be14-2f99-b1c4400850b8@gmail.com>

On 08/11, Kui-Feng Lee wrote:
> 
> 
> On 8/11/23 16:27, Kui-Feng Lee wrote:
> > 
> > 
> > On 8/11/23 16:05, Stanislav Fomichev wrote:
> > > On 08/10, thinker.li@gmail.com wrote:
> > > > From: Kui-Feng Lee <kuifeng@meta.com>
> > > > 
> > > > Provide bpf_copy_from_user() and bpf_copy_to_user() to the BPF programs
> > > > attached to cgroup/{set,get}sockopt. bpf_copy_to_user() is a new
> > > > kfunc to
> > > > copy data from an kernel space buffer to a user space buffer.
> > > > They are only
> > > > available for sleepable BPF programs. bpf_copy_to_user() is only
> > > > available
> > > > to the BPF programs attached to cgroup/getsockopt.
> > > > 
> > > > Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
> > > > ---
> > > >   kernel/bpf/cgroup.c  |  6 ++++++
> > > >   kernel/bpf/helpers.c | 31 +++++++++++++++++++++++++++++++
> > > >   2 files changed, 37 insertions(+)
> > > > 
> > > > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> > > > index 5bf3115b265c..c15a72860d2a 100644
> > > > --- a/kernel/bpf/cgroup.c
> > > > +++ b/kernel/bpf/cgroup.c
> > > > @@ -2461,6 +2461,12 @@ cg_sockopt_func_proto(enum bpf_func_id
> > > > func_id, const struct bpf_prog *prog)
> > > >   #endif
> > > >       case BPF_FUNC_perf_event_output:
> > > >           return &bpf_event_output_data_proto;
> > > > +
> > > > +    case BPF_FUNC_copy_from_user:
> > > > +        if (prog->aux->sleepable)
> > > > +            return &bpf_copy_from_user_proto;
> > > > +        return NULL;
> > > 
> > > If we just allow copy to/from, I'm not sure I understand how the buffer
> > > sharing between sleepable/non-sleepable works.
> > > 
> > > Let's assume I have two progs in the chain:
> > > 1. non-sleepable - copies the buffer, does some modifications; since
> > >     we don't copy the buffer back after every prog run, the modifications
> > >     stay in the kernel buffer
> > > 2. sleepable - runs and just gets the user pointer? does it mean this
> > >    sleepable program doesn't see the changes from (1)?
> 
> It is still visible from sleepable programs.  Sleepable programs
> will receive a pointer to the buffer in the kernel.
> And, BPF_SOCKOPT_FLAG_OPTVAL_USER is clear.
> 
> > > 
> > > IOW, do we need some custom sockopt copy_to/from that handle this
> > > potential buffer location transparently or am I missing something?
> > > 
> > > Assuming we want to support this at all. If we do, might deserve a
> > > selftest.
> > 
> > It is why BPF_SOCKOPT_FLAG_OPTVAL_USER is there.
> > It helps programs to make a right decision.
> > However, I am going to remove bpf_copy_from_user()
> > since we have bpf_so_optval_copy_to() and bpf_so_optval_copy_to_r().
> > Does it make sense to you?

Ah, so that's where it's handled. I didn't read that far :-)
In this case yes, let's have only those helpers.

Btw, do we also really need bpf_so_optval_copy_to_r? If we are doing
dynptr, let's only have bpf_so_optval_copy_to version?

I'd also call them something like bpf_sockopt_copy_{to,from}. That
"_so_optval_" is not super intuitive imho.

  reply	other threads:[~2023-08-14 17:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11  4:31 [RFC bpf-next v2 0/6] Sleepable BPF programs on cgroup {get,set}sockopt thinker.li
2023-08-11  4:31 ` [RFC bpf-next v2 1/6] bpf: enable sleepable BPF programs attached to cgroup/{get,set}sockopt thinker.li
2023-08-11 23:01   ` Stanislav Fomichev
2023-08-11 23:17     ` Kui-Feng Lee
2023-08-11 23:22     ` Kui-Feng Lee
2023-08-11  4:31 ` [RFC bpf-next v2 2/6] bpf: Prevent BPF programs from access the buffer pointed by user_optval thinker.li
2023-08-11  6:27   ` Yonghong Song
2023-08-11 16:01     ` Kui-Feng Lee
2023-08-11  4:31 ` [RFC bpf-next v2 3/6] bpf: rename bpf_copy_to_user() thinker.li
2023-08-11  4:31 ` [RFC bpf-next v2 4/6] bpf: Provide bpf_copy_from_user() and bpf_copy_to_user() thinker.li
2023-08-11 23:05   ` Stanislav Fomichev
2023-08-11 23:27     ` Kui-Feng Lee
2023-08-11 23:31       ` Kui-Feng Lee
2023-08-14 17:07         ` Stanislav Fomichev [this message]
2023-08-14 19:20           ` Kui-Feng Lee
2023-08-14 20:16             ` Stanislav Fomichev
2023-08-11  4:31 ` [RFC bpf-next v2 5/6] bpf: Add a new dynptr type for CGRUP_SOCKOPT thinker.li
2023-08-14  5:03   ` kernel test robot
2023-08-11  4:31 ` [RFC bpf-next v2 6/6] bpf: Add test cases for sleepable BPF programs of the CGROUP_SOCKOPT type thinker.li

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=ZNpfTBh4cC1oW8Cf@google.com \
    --to=sdf@google.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kuifeng@meta.com \
    --cc=martin.lau@linux.dev \
    --cc=sinquersw@gmail.com \
    --cc=song@kernel.org \
    --cc=thinker.li@gmail.com \
    --cc=yonghong.song@linux.dev \
    /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.