netdev - rfc: making rds-tcp netns aware

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

Message-ID: <20150715110453.GH6541@oracle.com>
Date:	Wed, 15 Jul 2015 13:04:53 +0200
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	netdev@...r.kernel.org
Cc:	sowmini.varadhan@...cle.com
Subject: rfc: making rds-tcp netns aware

I am working on making rds-tcp to be netns-aware, and in addition
to a few bug fixes that I'm lining up, there's a basic issue with 
the way rds-tcp sets up the listen socket that is causing problems

The RDS tcp listen endpoint is created as part of module init.
(rds_tcp_init -> rds_tcp_listen_init()). So this means that
if I create a "blue" netns, and 'modprobe rds_tcp' within that netns,
I get a kernel socket attached to the blue netns (which is good),
but then I cannot use the same technique to set up a socket
for a different netns ('modprobe rds_tcp' in that netns 
will return silently, as it should). 

And there's another downside to this design: the socket wont
get released till the module is unloaed, so it ends up holding
the reference on the net.

So perhaps it was not a good idea to set up the listen socket
as part of module init, but I'm trying to figure out a clean
design for setting up the listen socket.

Some uspace daemon that listens for changes to namespaces and
reacts appropriately? A separate sysctl that sets up the listen
endpoint in each namespace? 

Are there other subsystems that have to handle a similar case?  
I suspect that RDS-TCP is somewhat unusual here- I think most other
similar encaps protocols like vxlan etc are associated with a network 
driver, so the listen endpoint is created as part of the ->ndo_open

Suggestions for other modules that have to deal with a similar
situation that I can refer to are invited..

--Sowmini

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html