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

[John Fastabend <john.fastabend@gmail.com>]

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@gmail.com>
> > Acked-by: Yonghong Song <yhs@fb.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