netdev - Re: [bpf-next PATCH v4 2/5] bpf: extend bpf_base_func_proto helpers with probe_* and *current

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5ec94f7eb8377_103c2ab70a8e65c0d1@john-XPS-13-9370.notmuch>
Date:   Sat, 23 May 2020 09:29:50 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>, yhs@...com,
        andrii.nakryiko@...il.com, ast@...nel.org
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org, jakub@...udflare.com,
        lmb@...udflare.com
Subject: Re: [bpf-next PATCH v4 2/5] bpf: extend bpf_base_func_proto helpers
 with probe_* and *current_task*

Daniel Borkmann wrote:
> On 5/22/20 6:24 AM, John Fastabend wrote:
> > Often it is useful when applying policy to know something about the
> > task. If the administrator has CAP_SYS_ADMIN rights then they can
> > use kprobe + networking hook and link the two programs together to
> > accomplish this. However, this is a bit clunky and also means we have
> > to call both the network program and kprobe program when we could just
> > use a single program and avoid passing metadata through sk_msg/skb->cb,
> > socket, maps, etc.
> > 
> > To accomplish this add probe_* helpers to bpf_base_func_proto programs
> > guarded by a perfmon_capable() check. New supported helpers are the
> > following,
> > 
> >   BPF_FUNC_get_current_task
> >   BPF_FUNC_current_task_under_cgroup
> >   BPF_FUNC_probe_read_user
> >   BPF_FUNC_probe_read_kernel
> >   BPF_FUNC_probe_read_user_str
> >   BPF_FUNC_probe_read_kernel_str
> > 
> > Signed-off-by: John Fastabend <john.fastabend@...il.com>
> > Acked-by: Yonghong Song <yhs@...com>

[...]

> >   bpf_base_func_proto(enum bpf_func_id func_id)
> >   {
> > @@ -648,6 +655,26 @@ bpf_base_func_proto(enum bpf_func_id func_id)
> >   	case BPF_FUNC_jiffies64:
> >   		return &bpf_jiffies64_proto;
> >   	default:
> > +		break;
> > +	}
> > +
> > +	if (!perfmon_capable())
> > +		return NULL;
> > +
> > +	switch (func_id) {
> > +	case BPF_FUNC_get_current_task:
> > +		return &bpf_get_current_task_proto;
> > +	case BPF_FUNC_current_task_under_cgroup:
> > +		return &bpf_current_task_under_cgroup_proto;
> 
> Afaics, the map creation of BPF_MAP_TYPE_CGROUP_ARRAY is only tied to CAP_BPF and
> the bpf_current_task_under_cgroup() technically is not strictly tracing related.
> We do have similar bpf_skb_under_cgroup() for this map type in networking, for
> example, so 'current' is the only differentiator between the two.
> 
> Imho, the get_current_task() and memory probes below are fine and perfmon_capable()
> is also required for them. It's just that this one above stands out from the rest,
> and while thinking about it, what is the rationale for enabling bpf_current_task_under_cgroup()
> but not e.g. bpf_get_current_cgroup_id() or bpf_get_current_ancestor_cgroup_id() helpers
> that you've added in prior patch to sk_msg_func_proto()? What makes these different?

I think the only reason I split it like this is it required touching bpf_trace.c
on the code side.


> 
> The question is also wrt cgroup helpers on how reliable they could be used, say, in
> networking programs when we're under softirq instead of process context? Something
> would need to be documented at min, but I think it's probably best to say that we
> allow retrieving current and the probe mem helpers only, given for these cases you're
> on your own anyway and have to know what you're doing.. while the others can be used
> w/o much thought in some cases where we always have a valid current (like sock_addr
> progs), but not in others tc/BPF or XDP. Wdyt?
> 

That is a good analysis. Let me just drop the current_task_under_cgroup here and then
we can add it on a per context basis.

Thanks,
John