netdev - Re: Network RX per process per interface statistics

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: <ZCHN3sbx2Cr0r0hM@google.com>
Date:   Mon, 27 Mar 2023 10:09:50 -0700
From:   Stanislav Fomichev <sdf@...gle.com>
To:     Kamil Zaripov <zaripov-kamil@...ide.ai>
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network RX per process per interface statistics

On 03/27, Kamil Zaripov wrote:
> > By "modifies" - do you mean the payload/headers? You can probably use
> > the skb pointer address as a unique identifier to connect across  
> different
> > tracepoints?

> No, I mean when situations when same package through its way to the  
> network stack change sk_buff pointer. For example, after skb_clone()  
> call. I have made some test and found out (empirically) that pointer to  
> the skb->head a much better tracking ID. However, I am not sure that  
> there is no other corner cases when skb->head also can change.

Yeah, those are tricky :-(

> > Nothing pops to my mind. But I think that if you store skbaddr=dev from
> > netif_receive_skb, you should be able to look this up at a later point
> > where you know skb->process association?

> Yes, I have already implemented and make some test of this approach: I’m  
> listening at netif_receive_skb tracepoint to create skb_head->netif map  
> and then listening for __kfree_skb calls to create pid->skb_head map.  
> However, this approach have some weaknesses:
> - Part of packages of TCP protocol packages (ACK, for example) are  
> handled by the kernel, so I account this packages as kernel activity. But  
> almost every TCP ACK package have some  associated socket, which, in  
> turn, have associated process.
> - I am not sure that all package consumes call __kfree_skb at the end.  
> Maybe there is some other miscounting in this place.

> Maybe there is some other approaches to map packages to processes?

I'm not super familiar with those tracing hooks. Maybe you need to
handle consume_skb as well?

If I were to solve something like this, I'd probably look at cgroup/ingress
hooks. Those are guaranteed to run for every incoming packet into cgroup's
sockets. (at least removes that kfree_skb vs consume_skb issue).

But it doesn't solve your problem with the clones...