Re: [RFC PATCH bpf-next 0/3] bpf: Implement bpf_get_kern_btf_id() kfunc

[Yonghong Song <yhs@meta.com>]

On 11/15/22 8:30 AM, Toke Høiland-Jørgensen wrote:
> Yonghong Song <yhs@fb.com> 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