Re: [PATCH bpf-next 1/5] bpf: Allow helper bpf_get_ns_current_pid_tgid() in cgroup and sk_msg programs

[Yonghong Song <yonghong.song@linux.dev>]

On 3/9/24 11:10 AM, Alexei Starovoitov wrote:
> On Sat, Mar 9, 2024 at 10:40 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>> On 3/8/24 5:06 PM, Andrii Nakryiko wrote:
>>> On Thu, Mar 7, 2024 at 3:27 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>>> Currently bpf_get_current_pid_tgid() is allowed in tracing, cgroup
>>>> and sk_msg progs while bpf_get_ns_current_pid_tgid() is only allowed
>>>> in tracing progs.
>>>>
>>>> We have an internal use case where for an application running
>>>> in a container (with pid namespace), user wants to get
>>>> the pid associated with the pid namespace in a cgroup bpf
>>>> program. Currently, cgroup bpf progs already allow
>>>> bpf_get_current_pid_tgid(). Let us allow bpf_get_ns_current_pid_tgid()
>>>> as well.
>>>>
>>>> With auditing the code, bpf_get_current_pid_tgid() is also used
>>>> by sk_msg prog. So I added bpf_get_ns_current_pid_tgid()
>>>> support for sk_msg prog, so now for all places where
>>>> bpf_get_current_pid_tgid() can be used, bpf_get_ns_current_pid_tgid()
>>>> can be used as well.
>>>>
>>> If tracing can call both bpf_get_current_pid_tgid() and
>>> bpf_get_ns_current_pid_tgid(), can't we just add both into
>>> bpf_base_func_proto() and have them available for all types of BPF
>>> programs? If it's safe for tracing, it's safe for any program type, so
>>> why not?
>> Do we need any capability to control bpf_get_[ns_]current_pid_tgid()?
>> nothing or CAP_BPF or CAP_PERFMON? In my opinion, pid/tgid
>> is available to user space and there is no leaking kernel private
>> data here, so bpf prog should be able to use it in all prog types.
>> I will wait for a few days. If no people object, I will incorporate
>> this in v2.
> Yeah. It's safe without extra cap-s.
> There is ns_match() inside. Nothing can leak.
> Let's just move it to base_func_proto.

Sounds good. Will move both helpers to base_func_proto.