netdev - Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic

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

Date:	Mon, 6 Jan 2014 23:39:44 +0200
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Or Gerlitz <ogerlitz@...lanox.com>, Jerry Chu <hkchu@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Yan Burman <yanb@...lanox.com>,
	Shlomo Pongratz <shlomop@...lanox.com>
Subject: Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic

On Mon, Jan 6, 2014 at 8:46 PM, Tom Herbert <therbert@...gle.com> wrote:
> On Mon, Jan 6, 2014 at 10:13 AM, Or Gerlitz <or.gerlitz@...il.com> wrote:
>> On Mon, Jan 6, 2014 at 6:50 PM, Tom Herbert <therbert@...gle.com> wrote:
>>> I think this would be a good start. We can further optimize the encap
>>> path later on.
>>
>> good, did you had the chance to look on the 2nd problem I was facing,
>> e.g how to prevent gro-ing encapsulated VM (this issue will not happen
>> for non-virtualization schemes, I think) udp packets which happen to
>> carry a destination port which belongs to an encapsulation protocol?
>> as I wrote earlier here, I was thinking to add some field to struct
>> napi_gro_cb which will be zeroed when the gro stacks starts to work on
>> the skb and set once we pass udp_gro_receive, such that if we arrive
>> again to udp_gro_recieve and this field is set, which means the
>> encapsulated
>> packet is udp one, we flush.
>
> I don't see what the problem is, GRO should not be recursively applied
> to an inner UDP header for encapsulation. The guest may try to do it's
> own version of GRO on an inner UDP packet, but interpreting the
> destination port correctly is its responsibility then.


I wasn't sure what do you mean by "GRO should not be recursively applied
to an inner UDP header for encapsulation", consider these three packets p1/p2/p3
who are vxlan encapsulated with the UDP port used by vxlan being X and are
structured as follows (the arrows depict the gro travels)


p1: ip --> udp dport X --> vxlan --> ip --> tcp  dportZ
p2: ip --> udp dport X --> vxlan --> ip --> udp dportY
p2: ip --> udp dport X --> vxlan --> ip --> udp dportX --> vxlan xxit!

p1 will safely land in the tcp gro code and be handled there

p2 will travel twice to the udp gro code and be flushed on the 2nd
time there since
there is no gro protocol handler for udp port Y

p3 will travel twice to the udp gro code but will not be flushed on
the 2nd time
since it has dport which is registered to have gro handler, as such
the 1st eight bytes
of its payload will be considered vxlan header and from there we will
not be going anywhere good.

My current solution is to mark packets while they manage to cross the
udp gro recv handler
and disallow crossing there twice.
--
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