Received-SPF: pass (google.com: domain of linux-kernel+bounces-132194-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240404010308.334604-1-void@manifault.com>
In-Reply-To: <20240404010308.334604-1-void@manifault.com>
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Date: Thu, 4 Apr 2024 15:18:57 -0700
Message-ID: <CAEf4BzaXDQVCYD3YrzLJTKu7idHZ0KGzSedWPwEX3v44Fq1vQA@mail.gmail.com>
Subject: Re: [PATCH bpf-next 1/2] bpf: Allow invoking kfuncs from
 BPF_PROG_TYPE_SYSCALL progs
To: David Vernet <void@manifault.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, 
	andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, 
	yonghong.song@linux.dev, john.fastabend@gmail.com, kpsingh@kernel.org, 
	sdf@google.com, haoluo@google.com, jolsa@kernel.org, 
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 3, 2024 at 6:03=E2=80=AFPM David Vernet <void@manifault.com> wr=
ote:
>
> Currently, a set of core BPF kfuncs (e.g. bpf_task_*, bpf_cgroup_*,
> bpf_cpumask_*, etc) cannot be invoked from BPF_PROG_TYPE_SYSCALL
> programs. The whitelist approach taken for enabling kfuncs makes sense:
> it not safe to call these kfuncs from every program type. For example,
> it may not be safe to call bpf_task_acquire() in an fentry to
> free_task().
>
> BPF_PROG_TYPE_SYSCALL, on the other hand, is a perfectly safe program
> type from which to invoke these kfuncs, as it's a very controlled
> environment, and we should never be able to run into any of the typical
> problems such as recursive invoations, acquiring references on freeing
> kptrs, etc. Being able to invoke these kfuncs would be useful, as
> BPF_PROG_TYPE_SYSCALL can be invoked with BPF_PROG_RUN, and would
> therefore enable user space programs to synchronously call into BPF to
> manipulate these kptrs.
>
> This patch therefore enables invoking the aforementioned core kfuncs
> from BPF_PROG_TYPE_SYSCALL progs.
>
> Signed-off-by: David Vernet <void@manifault.com>
> ---
>  kernel/bpf/cpumask.c | 1 +
>  kernel/bpf/helpers.c | 1 +
>  2 files changed, 2 insertions(+)
>

Makes sense, but see my comments on patch #2.

Acked-by: Andrii Nakryiko <andrii@kernel.org>

> diff --git a/kernel/bpf/cpumask.c b/kernel/bpf/cpumask.c
> index dad0fb1c8e87..33c473d676a5 100644
> --- a/kernel/bpf/cpumask.c
> +++ b/kernel/bpf/cpumask.c
> @@ -474,6 +474,7 @@ static int __init cpumask_kfunc_init(void)
>         ret =3D bpf_mem_alloc_init(&bpf_cpumask_ma, sizeof(struct bpf_cpu=
mask), false);
>         ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &=
cpumask_kfunc_set);
>         ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS=
, &cpumask_kfunc_set);
> +       ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL, &=
cpumask_kfunc_set);
>         return  ret ?: register_btf_id_dtor_kfuncs(cpumask_dtors,
>                                                    ARRAY_SIZE(cpumask_dto=
rs),
>                                                    THIS_MODULE);
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index d9e7aca8ae9e..8cde717137bd 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2653,6 +2653,7 @@ static int __init kfunc_init(void)
>         ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS,=
 &generic_kfunc_set);
>         ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_XDP, &gene=
ric_kfunc_set);
>         ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS=
, &generic_kfunc_set);
> +       ret =3D ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL, &=
generic_kfunc_set);
>         ret =3D ret ?: register_btf_id_dtor_kfuncs(generic_dtors,
>                                                   ARRAY_SIZE(generic_dtor=
s),
>                                                   THIS_MODULE);
> --
> 2.44.0
>