netdev - Re: [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports

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:	Fri, 19 Feb 2016 16:59:42 +0900
From:	Simon Horman <simon.horman@...ronome.com>
To:	Jesse Gross <jesse@...nel.org>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	ovs dev <dev@...nvswitch.org>,
	Pravin Shelar <pshelar@...ira.com>
Subject: Re: [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to
 tunnel vports

On Tue, Feb 16, 2016 at 02:53:39PM -0800, Jesse Gross wrote:
> On Fri, Feb 12, 2016 at 11:25 AM, Simon Horman
> <simon.horman@...ronome.com> wrote:
> > If an skb was not MPLS initially then it may be GSO and in that case if it
> > became MPLS then GSO can't be performed because both MPLS and tunnels make
> > use of the inner_protocol field of struct skbuff in order to allow GSO to
> > be performed in the inner packet.
> >
> > On the other hand if an skb was MPLS initially then it will not be GSO,
> > as there is no support for GRO for MPLS. Thus in this case it is safe
> > to allow output of MPLS on tunnel vports.
> >
> > Signed-off-by: Simon Horman <simon.horman@...ronome.com>
> 
> I don't think that any tunnel implementations expose support for MPLS
> offloads as part of their features. In that case, if we have an MPLS
> GSO packet (regardless of how it came to be), I think it will be
> broken apart in software before encapsulation. At that point, it
> should be safe for the tunnel to overwrite any fields MPLS was
> previously using for offloading. As a result, I believe we can allow
> all combinations of MPLS with tunnels. (Note that historically this
> wasn't true, the change is a result of lightweight tunnels.)

Hi Jesse,

wow, that does sound very promising.
I would certainly be in favour of allowing MPLS with tunnels.

I am wondering if you could point me in the general direction of the changes
you mention above.