[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Apr 2024 08:32:27 -0700
From: Yonghong Song <yonghong.song@...ux.dev>
To: David Vernet <void@...ifault.com>, bpf@...r.kernel.org
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
martin.lau@...ux.dev, song@...nel.org, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org,
linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH bpf-next 1/2] bpf: Allow invoking kfuncs from
BPF_PROG_TYPE_SYSCALL progs
On 4/3/24 6:03 PM, David Vernet wrote:
> 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@...ifault.com>
Acked-by: Yonghong Song <yonghong.song@...ux.dev>
Powered by blists - more mailing lists