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? -Toke
