netdev - Re: RFC: Should net namespaces scale up (>10k) ?

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

Message-ID: <CAKYWH0Ti3=4GeeuVyWKJ9LyTuRnf3Wy9GKg4Jb7tdeaT39qADA@mail.gmail.com>
Date: Sun, 15 Sep 2024 22:49:22 +0200
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: horms@...nel.org
Cc: Alexandre Ferrieux <alexandre.ferrieux@...nge.com>, Eric Dumazet <edumazet@...gle.com>, 
	netdev@...r.kernel.org
Subject: Re: RFC: Should net namespaces scale up (>10k) ?

(thanks Simon, reposting with another account to avoid the offending disclaimer)

Hi,

Currently, netns don't really scale beyond a few thousands, for
mundane reasons (see below). But should they ? Is there, in the
design, an assumption that tens of thousands of network namespaces are
considered "unreasonable" ?

A typical use case for such ridiculous numbers is a tester for
firewalls or carrier-grade NATs. In these, you typically want tens of
thousands of tunnels, each of which is perfectly instantiated as an
interface. And, to avoid an explosion in source routing rules, you
want them in separate namespaces.

Now why don't they scale *today* ? For two independent, seemingly
accidental, O(N) scans of the netns list.

1. The "netdevice notifier" from the Wireless Extensions subsystem
insists on scanning the whole list regardless of the nature of the
change, nor wondering whether all these namespaces hold any wireless
interface, nor even whether the system has _any_ wireless hardware...

        for_each_net(net) {
                while ((skb = skb_dequeue(&net->wext_nlevents)))
                        rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
                                    GFP_KERNEL);
        }

2. When moving an interface (eg an IPVLAN slave) to another netns,
__dev_change_net_namespace() calls peernet2id_alloc() in order to get
an ID for the target namespace. This again incurs a full scan of the
netns list:

        int id = idr_for_each(&net->netns_ids, net_eq_idr, peer);

Note that, while IDR is very fast when going from ID to pointer, the
reverse path is awfully slow... But why are IDs needed in the first
place, instead of the simple netns pointers ?

Any insight on the (possibly very good) reasons those two apparent
warts stand in the way of netns scaling up ?

-Alex