netdev - Re: [question] robust netns association with fib4 lookup

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: <1d99d7ccfc3a7a18840948ab6ba1c0b5fad90901.camel@fejes.dev>
Date: Tue, 29 Apr 2025 07:50:10 +0200
From: Ferenc Fejes <ferenc@...es.dev>
To: Ido Schimmel <idosch@...dia.com>
Cc: dsahern@...il.com, netdev <netdev@...r.kernel.org>, kuniyu@...zon.com
Subject: Re: [question] robust netns association with fib4 lookup

On Mon, 2025-04-28 at 18:35 +0300, Ido Schimmel wrote:
> On Mon, Apr 28, 2025 at 12:20:06PM +0200, Ferenc Fejes wrote:
> > On Fri, 2025-04-25 at 21:17 +0300, Ido Schimmel wrote:
> > > On Thu, Apr 24, 2025 at 01:33:08PM +0200, Ferenc Fejes wrote:

...

> > > > Unfortunately this includes some callers to fib_table_lookup. The
> > > > netns id would also be presented in the existing tracepoints ([1] and
> > > > [2]). Thanks in advance for any suggestion.
> > > 
> > > By "netns id" you mean the netns cookie? It seems that some TCP trace
> > > events already expose it (see include/trace/events/tcp.h). It would be
> > > nice to finally have "perf" filter these FIB events based on netns.
> > 
> > No, by netns id I mean struct net::ns::inum, which is the inode number
> > associated with the netns. This is convenient since it's easy to look up
> > this
> > value in userspace with the lsns tool or just stat through the procfs for
> > the
> > inode.
> > 
> > Looks like struct net::net_cookie is for similar purpose and can be used
> > from
> > restricted context (e.g.: xdp/tc/cls eBPF progs) where rich context (struct
> > net
> > for example) as in a fexit/fentry probe is not available.
> 
> I'm not sure the inode number is a good identifier for a namespace. See
> this comment from the namespace maintainer for a patch that tried to add
> a BPF helper to read this value:
> 
> https://lore.kernel.org/all/87efzq8jbi.fsf@xmission.com/

Thanks for the pointer, this makes it crystal clear why the cookie is the way to
go. The TCP tracepoints also stick with the coockie. 

> 
> More here:
> 
> https://lore.kernel.org/netdev/87h93xqlui.fsf@xmission.com/
> 
> Which I suspect is why Daniel added the netns cookie:
> 
> https://lore.kernel.org/bpf/c47d2346982693a9cf9da0e12690453aded4c788.1585323121.git.daniel@iogearbox.net/
> 
> Regarding retrieval of this cookie, there is SO_NETNS_COOKIE:
> 
> https://lore.kernel.org/all/20210623135646.1632083-1-m@lambda.lt/
> 
> Seems to work fine [1]. Maybe ip-netns can be extended to retrieve the
> cookie with something like:
> 
> ip netns cookie [ NETNSNAME | PID ]

Agree, the exposure of the cookie for the userspace with ip netns or lsns would
be useful. Luckily [1] is straightforward enough and makes the netns
identification trivial.

> 
> [1]
> # cat so_netns_cookie.c
> #include <unistd.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> 
> int main(int argc, char *argvp[])
> {
>         socklen_t vallen;
>         uint64_t cookie;
>         int sock;
> 
>         sock = socket(AF_INET, SOCK_STREAM, 0);
>         if (sock < 0)
>                 return sock;
> 
>         vallen = sizeof(cookie);
>         if (getsockopt(sock, SOL_SOCKET, SO_NETNS_COOKIE, &cookie, &vallen) !=
> 0)
>                 return -1;
> 
>         printf("cookie = %lu\n", cookie);
> 
>         close(sock);
> 
>         return 0;
> }
> # gcc -Wall so_netns_cookie.c -o so_netns_cookie
> # ip netns add ns1
> # ip netns add ns2
> # ./so_netns_cookie
> cookie = 1
> # ip netns exec ns1 ./so_netns_cookie
> cookie = 2
> # ip netns exec ns2 ./so_netns_cookie
> cookie = 3