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]
Date:	Tue, 13 May 2014 08:28:23 -0700
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	sowmini varadhan <sowmini05@...il.com>
Cc:	netdev <netdev@...r.kernel.org>, JP Abgrall <jpa@...gle.com>,
	David Miller <davem@...emloft.net>,
	Julian Anastasov <ja@....bg>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: [PATCH 0/3] Make mark-based routing work better with multiple
 separate networks.

On Tue, May 13, 2014 at 3:49 AM, sowmini varadhan <sowmini05@...il.com> wrote:
> Specifically addressing the two issues raised above:
> - yes, it is true that an interface can exist in only one netns at a time.
>   But the same ip address can exist in multiple netns-es. If the
>   app wants to listen to a proper-subset of networks that go in/out
>   a single physical interface, you can use macvlan, and assign the
>   macvlans to the desired netns.

You can't use macvlan if you're not using interfaces that don't have
MAC addresses such as tun devices, 4G interfaces, and so on.

> - "same listening socket for multiple namespaces". Clearly that problem
>   also exists for the socket-marks approach. But again this can actually
>   be solved (for both netns and sock-marks) by having the application
>   set up separate sockets for each netns (netns or whatever) of interest,
>   and build an epoll fd over that set of sockets. No need for any kernel
>   code for this.

IMO forcing an application to open one socket per namespace, and
constantly be listening for any namespace changes as networks come and
go, is an unreasonable burden when all the application wants to do is
"accept connections on port 80 from everywhere". It's true that it
requires no kernel code, but you could also observe that no kernel
code is required for TCP, since it can all be done by the app using
raw sockets.

> My point is: what is the real networking construct that this use-case needs?
> Isn't it what routers describe as the VRF? If yes, then shouldnt
> we have one single way of supporting that in linux, instead of having
> a little-bit-here and a little-bit-there?

This is not a little-bit-here and a little-bit there. Socket marking
is an existing feature and this patch makes it work better when
different fwmarks identify different networks, without needing
namespace isolation, moving sockets between namespaces, etc.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ