netdev - Re: [PATCH net-next 1/2] Support outside netns for tunnels.

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: <1451937248.4334.105.camel@perches.com>
Date:	Mon, 04 Jan 2016 11:54:08 -0800
From:	Joe Perches <joe@...ches.com>
To:	Tom Herbert <tom@...bertland.com>,
	Saurabh Mohan <saurabh@...anenetworks.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	"David S. Miller" <davem@...emloft.net>,
	Pravin B Shelar <pshelar@...ira.com>,
	Thomas Graf <tgraf@...g.ch>
Subject: Re: [PATCH net-next 1/2] Support outside netns for tunnels.

On Mon, 2016-01-04 at 11:47 -0800, Tom Herbert wrote:
> On Mon, Jan 4, 2016 at 10:45 AM, Saurabh Mohan
> <saurabh@...anenetworks.com> wrote:
> > 
> > This patch enchances a tunnel interface, like gre, to have the tunnel
> > encap/decap be in the context of a network namespace that is different from
> > the namespace of the tunnel interface.
> > 
> > From userspace this feature may be configured using the new 'onetns' keyword:
> > ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
> >  remote 10.0.0.2 onetns outside
> > 
> > In the above example the tunnel would be in the 'custa' namespace and the
> > tunnel endpoints would be in the 'outside' namespace.
> > 
> > Also, proposing the use of netns name 'global' to specify the global namespace.
> > 
> > If this patch set is accepted then I will add support for other tunnels as
> > well.
> > 
> This might be interesting. Can you please ad a 0/n patch that
> describes the motivation for this, in particular I would like to know
> if this has a positive impact on ns performance if somehow we are
> eliminating indirection.
[]
> > diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
[]
> > @@ -3,6 +3,7 @@
> > 
> >  #include 
> >  #include 
> > +#include 
> > 
> > 
> >  #define SIOCGETTUNNEL   (SIOCDEVPRIVATE + 0)
> > @@ -27,6 +28,14 @@
> >  #define GRE_FLAGS      __cpu_to_be16(0x00F8)
> >  #define GRE_VERSION    __cpu_to_be16(0x0007)
> > 
> > +struct o_netns_parm {
> > +       __u8                    o_netns_flag;
> > +       __u32                   o_netns_fd;
> > +       char                    netns[NAME_MAX];
> > +};

Trivia:

It could eliminate a few padding bytes if the
o_netns_fd and o_netns_flag fields were reversed.

and netns[NAME_MAX] is normally netns[NAME_MAX + 1]

--
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