From: Anton Protopopov <aspsk@isovalent.com>
To: Hou Tao <houtao@huaweicloud.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 3/6] bpf: add fd_array_cnt attribute for prog_load
Date: Wed, 27 Nov 2024 06:44:13 +0000 [thread overview]
Message-ID: <Z0a/vaxyp4Gnk3TE@eis> (raw)
In-Reply-To: <1b5f9aba-d7de-a677-0a5f-89237c8f62a4@huaweicloud.com>
On 24/11/26 10:11AM, Hou Tao wrote:
> Hi,
>
> On 11/19/2024 6:15 PM, Anton Protopopov wrote:
> > The fd_array attribute of the BPF_PROG_LOAD syscall may contain a set
> > of file descriptors: maps or btfs. This field was introduced as a
> > sparse array. Introduce a new attribute, fd_array_cnt, which, if
> > present, indicates that the fd_array is a continuous array of the
> > corresponding length.
> >
> > If fd_array_cnt is non-zero, then every map in the fd_array will be
> > bound to the program, as if it was used by the program. This
> > functionality is similar to the BPF_PROG_BIND_MAP syscall, but such
> > maps can be used by the verifier during the program load.
> >
> > Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
> > ---
> > include/uapi/linux/bpf.h | 10 ++++
> > kernel/bpf/syscall.c | 2 +-
> > kernel/bpf/verifier.c | 106 ++++++++++++++++++++++++++++-----
> > tools/include/uapi/linux/bpf.h | 10 ++++
> > 4 files changed, 113 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index 4162afc6b5d0..2acf9b336371 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -1573,6 +1573,16 @@ union bpf_attr {
> > * If provided, prog_flags should have BPF_F_TOKEN_FD flag set.
> > */
> > __s32 prog_token_fd;
> > + /* The fd_array_cnt can be used to pass the length of the
> > + * fd_array array. In this case all the [map] file descriptors
> > + * passed in this array will be bound to the program, even if
> > + * the maps are not referenced directly. The functionality is
> > + * similar to the BPF_PROG_BIND_MAP syscall, but maps can be
> > + * used by the verifier during the program load. If provided,
> > + * then the fd_array[0,...,fd_array_cnt-1] is expected to be
> > + * continuous.
> > + */
> > + __u32 fd_array_cnt;
> > };
> >
> > struct { /* anonymous struct used by BPF_OBJ_* commands */
>
> SNIP
> > +/*
> > + * The add_fd_from_fd_array() is executed only if fd_array_cnt is given. In
> > + * this case expect that every file descriptor in the array is either a map or
> > + * a BTF, or a hole (0). Everything else is considered to be trash.
> > + */
> > +static int add_fd_from_fd_array(struct bpf_verifier_env *env, int fd)
> > +{
> > + struct bpf_map *map;
> > + CLASS(fd, f)(fd);
> > + int ret;
> > +
> > + map = __bpf_map_get(f);
> > + if (!IS_ERR(map)) {
> > + ret = add_used_map(env, map);
> > + if (ret < 0)
> > + return ret;
> > + return 0;
> > + }
> > +
> > + if (!IS_ERR(__btf_get_by_fd(f)))
> > + return 0;
>
> For fd_array_cnt > 0 case, does it need to handle BTF fd case ? If it
> does, these returned BTFs should be saved in somewhere, otherewise,
> these BTFs will be leaked.
ATM we don't actually store BTFs here. The __btf_get_by_fd doesn't
increase the refcnt, so no leaks.
> > + if (!fd)
> > + return 0;
> > +
> > + verbose(env, "fd %d is not pointing to valid bpf_map or btf\n", fd);
> > + return PTR_ERR(map);
> > +}
> > +
> > +static int env_init_fd_array(struct bpf_verifier_env *env, union bpf_attr *attr, bpfptr_t uattr)
> > +{
> > + int size = sizeof(int) * attr->fd_array_cnt;
> > + int *copy;
> > + int ret;
> > + int i;
> > +
> > + if (attr->fd_array_cnt >= MAX_USED_MAPS)
> > + return -E2BIG;
> > +
> > + env->fd_array = make_bpfptr(attr->fd_array, uattr.is_kernel);
> > +
> > + /*
> > + * The only difference between old (no fd_array_cnt is given) and new
> > + * APIs is that in the latter case the fd_array is expected to be
> > + * continuous and is scanned for map fds right away
> > + */
> > + if (!size)
> > + return 0;
> > +
> > + copy = kzalloc(size, GFP_KERNEL);
> > + if (!copy)
> > + return -ENOMEM;
> > +
> > + if (copy_from_bpfptr_offset(copy, env->fd_array, 0, size)) {
> > + ret = -EFAULT;
> > + goto free_copy;
> > + }
>
> It is better to use kvmemdup_bpfptr() instead.
Thanks for the hint. As suggested by Alexei, I will remove the memory
allocation here altogether.
> > +
> > + for (i = 0; i < attr->fd_array_cnt; i++) {
> > + ret = add_fd_from_fd_array(env, copy[i]);
> > + if (ret)
> > + goto free_copy;
> > + }
> > +
> > +free_copy:
> > + kfree(copy);
> > + return ret;
> > +}
> > +
> > int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr, __u32 uattr_size)
> > {
> > u64 start_time = ktime_get_ns();
> > @@ -22557,7 +22632,9 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr, __u3
> > env->insn_aux_data[i].orig_idx = i;
> > env->prog = *prog;
> > env->ops = bpf_verifier_ops[env->prog->type];
> > - env->fd_array = make_bpfptr(attr->fd_array, uattr.is_kernel);
> > + ret = env_init_fd_array(env, attr, uattr);
> > + if (ret)
> > + goto err_free_aux_data;
>
> These maps saved in env->used_map will also be leaked.
Yeah, thanks, actually, env->used_map contents will be leaked (if
error occurs here or until we get to after `goto err_unlock`), so
I will rewrite the init/error path.
> >
> > env->allow_ptr_leaks = bpf_allow_ptr_leaks(env->prog->aux->token);
> > env->allow_uninit_stack = bpf_allow_uninit_stack(env->prog->aux->token);
> > @@ -22775,6 +22852,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr, __u3
> > err_unlock:
> > if (!is_priv)
> > mutex_unlock(&bpf_verifier_lock);
> > +err_free_aux_data:
> > vfree(env->insn_aux_data);
> > kvfree(env->insn_hist);
> > err_free_env:
> > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> > index 4162afc6b5d0..2acf9b336371 100644
> > --- a/tools/include/uapi/linux/bpf.h
> > +++ b/tools/include/uapi/linux/bpf.h
> > @@ -1573,6 +1573,16 @@ union bpf_attr {
> > * If provided, prog_flags should have BPF_F_TOKEN_FD flag set.
> > */
> > __s32 prog_token_fd;
> > + /* The fd_array_cnt can be used to pass the length of the
> > + * fd_array array. In this case all the [map] file descriptors
> > + * passed in this array will be bound to the program, even if
> > + * the maps are not referenced directly. The functionality is
> > + * similar to the BPF_PROG_BIND_MAP syscall, but maps can be
> > + * used by the verifier during the program load. If provided,
> > + * then the fd_array[0,...,fd_array_cnt-1] is expected to be
> > + * continuous.
> > + */
> > + __u32 fd_array_cnt;
> > };
> >
> > struct { /* anonymous struct used by BPF_OBJ_* commands */
>
next prev parent reply other threads:[~2024-11-27 6:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-19 10:15 [PATCH v2 bpf-next 0/6] Add fd_array_cnt attribute for BPF_PROG_LOAD Anton Protopopov
2024-11-19 10:15 ` [PATCH v2 bpf-next 1/6] bpf: add a __btf_get_by_fd helper Anton Protopopov
2024-11-26 1:31 ` Alexei Starovoitov
2024-11-26 16:33 ` Anton Protopopov
2024-11-26 16:52 ` Alexei Starovoitov
2024-11-19 10:15 ` [PATCH v2 bpf-next 2/6] bpf: move map/prog compatibility checks Anton Protopopov
2024-11-26 18:44 ` Andrii Nakryiko
2024-11-19 10:15 ` [PATCH v2 bpf-next 3/6] bpf: add fd_array_cnt attribute for prog_load Anton Protopopov
2024-11-26 1:38 ` Alexei Starovoitov
2024-11-26 17:05 ` Anton Protopopov
2024-11-26 18:51 ` Andrii Nakryiko
2024-11-26 20:40 ` Alexei Starovoitov
2024-11-27 6:54 ` Anton Protopopov
2024-11-27 6:49 ` Anton Protopopov
2024-11-26 2:11 ` Hou Tao
2024-11-27 6:44 ` Anton Protopopov [this message]
2024-11-28 4:15 ` Hou Tao
2024-11-19 10:15 ` [PATCH v2 bpf-next 4/6] selftests/bpf: Add tests for fd_array_cnt Anton Protopopov
2024-11-26 18:54 ` Andrii Nakryiko
2024-11-27 6:45 ` Anton Protopopov
2024-11-19 10:15 ` [PATCH v2 bpf-next 5/6] bpf: fix potential error return Anton Protopopov
2024-11-26 1:43 ` Alexei Starovoitov
2024-11-26 16:36 ` Anton Protopopov
2024-11-19 10:15 ` [PATCH v2 bpf-next 6/6] selftest/bpf: replace magic constants by macros Anton Protopopov
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=Z0a/vaxyp4Gnk3TE@eis \
--to=aspsk@isovalent.com \
--cc=bpf@vger.kernel.org \
--cc=houtao@huaweicloud.com \
/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