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, 16 Feb 2016 14:53:39 -0800
From:	Jesse Gross <jesse@...nel.org>
To:	Simon Horman <simon.horman@...ronome.com>
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 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.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ