netdev - Re: [PATCH net-next 0/5] net: Improve netns handling in RTNL and ip

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABAhCOQ60u9Bkatbg6bc7CksMTXDw8v06SDsfv77YpEQW+anZg@mail.gmail.com>
Date: Wed, 30 Oct 2024 10:10:32 +0800
From: Xiao Liang <shaw.leon@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, 
	David Ahern <dsahern@...nel.org>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Kuniyuki Iwashima <kuniyu@...zon.com>, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 0/5] net: Improve netns handling in RTNL and ip_tunnel

On Wed, Oct 30, 2024 at 7:17 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 23 Oct 2024 10:31:41 +0800 Xiao Liang wrote:
> > This patch series includes some netns-related improvements and fixes for
> > RTNL and ip_tunnel, to make link creation more intuitive:
> >
> >  - Creating link in another net namespace doesn't conflict with link names
> >    in current one.
> >  - Add a flag in rtnl_ops, to avoid netns change when link-netns is present
> >    if possible.
> >  - When creating ip tunnel (e.g. GRE) in another netns, use current as
> >    link-netns if not specified explicitly.
> >
> > So that
> >
> >   # modprobe ip_gre netns_atomic=1
> >   # ip link add netns ns1 link-netns ns2 tun0 type gre ...
>
> Do you think the netns_atomic module param is really necessary?
> I doubt anyone cares about the event popping up in the wrong
> name space first.

We used FRRouting in our solution which listens to link notifications to
set up corresponding objects in userspace. Since the events are sent
in different namespaces (thus via different RTNL sockets), we can't
guarantee that the events are received in the correct order, and have
trouble processing them. The way to solve this problem I can think of is
to have a multi-netns RTNL socket where all events are synchronized,
or to eliminate the redundant events in the first place. The latter seems
easier to implement.

>
> BTW would be good to have tests for this. At least the behavior
> around name / ifindex collisions in different namespaces.
> You can possibly extend/re-purpose netns-name.sh for this.
>
> For notifications you could use python and subscribe to the events
> using a YNL socket. May be easier than dealing with ip monitor
> as a background process. But either way is fine.

I will try to add some tests. Thanks!