On 11/15/22 8:30 AM, Toke Høiland-Jørgensen wrote:
Yonghong Song <yhs@xxxxxx> writes:Currenty, a non-tracing bpf program typically has a single 'context' argument with predefined uapi struct type. Following these uapi struct, user is able to access other fields defined in uapi header. Inside the kernel, the user-seen 'context' argument is replaced with 'kernel context' (or 'kcontext' in short) which can access more information than what uapi header provides. To access other info not in uapi header, people typically do two things: (1). extend uapi to access more fields rooted from 'context'. (2). use bpf_probe_read_kernl() helper to read particular field based on kcontext. Using (1) needs uapi change and using (2) makes code more complex since direct memory access is not allowed. There are already a few instances trying to access more information from kcontext: (1). trying to access some fields from perf_event kcontext. (2). trying to access some fields from xdp kcontext. This patch set tried to allow direct memory access for kcontext fields by introducing bpf_get_kern_btf_id() kfunc.I think the general idea is neat. However, I'm a bit concerned that with this we're allowing networking BPF programs (like XDP) to walk more or less arbitrary kernel structures, which has thus far been something only tracing programs have had access to. So we probably require programs to have CAP_PERFMON to use this kfunc, no?
Make sense, since the kfunc is to enable tracing, yes CAP_PERFMON is a good idea. I will make the change in the next revision.
-Toke
