diff options
author | Andrii Nakryiko <andrii@kernel.org> | 2024-04-05 10:56:09 -0700 |
---|---|---|
committer | Andrii Nakryiko <andrii@kernel.org> | 2024-04-05 10:59:04 -0700 |
commit | d564ffde5c832c46513e0189647abfde9833e590 (patch) | |
tree | 654f4867da71174bdb8586e55af19feae16fd6f8 /tools/lib/bpf | |
parent | 00d5d22a5b42c3ffdfd1b29526885bbcec2d2231 (diff) | |
parent | 1bc724af00cc48ef03e3fa6d7a2f6731ac915c37 (diff) |
Merge branch 'bpf-allow-invoking-kfuncs-from-bpf_prog_type_syscall-progs'
David Vernet says:
====================
bpf: Allow invoking kfuncs from BPF_PROG_TYPE_SYSCALL progs
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.
---
v1: https://lore.kernel.org/all/20240404010308.334604-1-void@manifault.com/
v1 -> v2:
- Create new verifier_kfunc_prog_types testcase meant to specifically
validate calling core kfuncs from various program types. Remove the
macros and testcases that had been added to the task, cgrp, and
cpumask kfunc testcases (Andrii and Yonghong)
====================
Link: https://lore.kernel.org/r/20240405143041.632519-1-void@manifault.com
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Diffstat (limited to 'tools/lib/bpf')
0 files changed, 0 insertions, 0 deletions