netdev - Re: [PATCH net-next v2 2/2] vxlan: Remote checksum offload

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: <20150113164011.GO20387@casper.infradead.org>
Date:	Tue, 13 Jan 2015 16:40:11 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Tom Herbert <therbert@...gle.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/2] vxlan: Remote checksum offload

[Moving this discussion to the thread of the respective patch]

On 01/13/15 at 08:16am, Tom Herbert wrote:
> On 01/13/15 at 11:44am, Thomas Graf wrote:
> > The major difference here is that we have to consider backwards
> > compatibility specifically for VXLAN. Your initial feedback on GPE
> > actually led me to how I implemented GBP.
> >
> > I think the axioms we want to establish are as follows:
> >  1. Extensions need to be explicitly enabled by the user. A previously
> >     dropped frame should only be processed if the user explitly asks
> >     for it.
> >  2. As a consequence: only share a VLXAN UDP port if the enabled
> >     extensions match (vxlan_sock_add), e.g. user A might want RCO
> >     but user B might be unaware. They cannot share the same UDP port.
> >
> > The 2nd lead me to introduce the 'exts' member to vxlan_sock so we can
> > compare it in vxlan_find_sock() and only share a UDP port if the
> > enabled extensions match.
> >
> RCO is represented in the socket in VXLAN flags (VLXAN_F_*). My patch
> also adds a flags to vxlan_sock which contains the VLXAN flags. For
> shared port, I suspect all the receive features must match, including
> receive checksum settings for instance, but we don't care about
> transmit side. To facilitate this, I would suggest splitting flags
> into o_flags and i_flags like ip_tunnel does, and then compare i_flags
> in vxlan_find_sock.

Not sure I understand why you want to omit the transmit side. If a
VXLAN socket with RCO TX enabled is found and shared with a user
who does not want RCO enabled, it will get RCO enabled frames which
will get dropped by non RCO VXLAN receivers.
--
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