Messages in this thread | | | Date | Tue, 16 Jun 2015 10:10:56 -0700 | From | Alexei Starovoitov <> | Subject | Re: [PATCH v2 net-next 0/3] bpf: share helpers between tracing and networking |
| |
On 6/16/15 2:19 AM, Daniel Borkmann wrote: > if you really want to, you > could go via skb->sk->sk_socket->file and then retrieve credentials > from there for egress side (you can have a look at xt_owner). You'd > need a different *_proto helper for tc in that case, which would > then map to BPF_FUNC_get_current_uid_gid, etc. But that doesn't work > for ingress however, even if you would have early demux, so you > would need to let the eBPF helper function return an error code in > that case.
was looking at cls_flow to do exactly that, but with different helper name. Like bpf_get_socket_uid_gid(). The use case is to collect network statistics per-user and per-process. I think android still using some out of tree hacks for that. Ingress indeed is not solved by this skb->sk->sk_socket approach. I considered kprobe style, but accessing skb->len via probe_read is kernel specific, nonportable and slow-ish. Ideally we would allow a blend of tracing and networking programs, then the best solution would be one or two stable tracepoints in networking stack where skb is visible and receiving/transmitting task is also visible, then skb->len and task->pid together would give nice foundation for accurate stats.
| |