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 <[email protected]>
> > Acked-by: Yonghong Song <[email protected]>
[...]
> > 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
