netdev - Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

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: <234d6a2f-6971-7029-0645-f98e51236c4f@redhat.com>
Date:	Tue, 21 Jun 2016 10:40:32 -0700
From:	Hannes Frederic Sowa <hannes@...hat.com>
To:	Edward Cree <ecree@...arflare.com>,
	Alexander Duyck <alexander.duyck@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	Tom Herbert <tom@...bertland.com>,
	Alex Duyck <aduyck@...antis.com>,
	Netdev <netdev@...r.kernel.org>,
	intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
	Jesse Gross <jesse@...nel.org>,
	Eugenia Emantayev <eugenia@...lanox.com>,
	Jiri Benc <jbenc@...hat.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Ariel Elior <ariel.elior@...gic.com>,
	Michael Chan <michael.chan@...adcom.com>,
	Dept-GELinuxNICDev@...gic.com
Subject: Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

On 21.06.2016 10:27, Edward Cree wrote:
> On 21/06/16 18:05, Alexander Duyck wrote:
>> On Tue, Jun 21, 2016 at 1:22 AM, David Miller <davem@...emloft.net> wrote:
>>> But anyways, the vastness of the key is why we want to keep "sockets"
>>> out of network cards, because proper support of "sockets" requires
>>> access to information the card simply does not and should not have.
>> Right.  Really what I would like to see for most of these devices is a
>> 2 tuple filter where you specify the UDP port number, and the PF/VF ID
>> that the traffic is received on.
> But that doesn't make sense - the traffic is received on a physical network
> port, and it's the headers (i.e. flow) at that point that determine whether
> the traffic is encap or not.  After all, those headers are all that can
> determine which PF or VF it's sent to; and if it's multicast and goes to
> more than one of them, it seems odd for one to treat it as encap and the
> other to treat it as normal UDP - one of them must be misinterpreting it
> (unless the UDP is going to a userspace tunnel endpoint, but I'm ignoring
> that complication for now).

Disabling offloading of packets is never going to cause data corruptions
or misinterpretations. In some cases we can hint the network card to do
even more (RSS+checksumming). We always have a safe choice, namely not
doing hw offloading.

Multicast is often scoped, in some cases we have different multicast
scopes but the same addresses. In case of scoped traffic, we must verify
the device as well and can't install the same flow on every NIC.

> At a given physical point in the network, a given UDP flow either is or is
> not carrying encapsulated traffic, and if it tries to be both then things
> are certain to break, just as much as if two different applications try to
> use the same UDP flow for two different application protocols.

I think the example Tom was hinting at initially is like that:

A net namespace acts as a router and has a vxlan endpoint active. The
vxlan endpoint enables vxlan offloading on all net_devices in the same
namespace. Because we only identify the tunnel endpoint by UDP port
number, traffic which should actually just be forwarded and should never
be processed locally suddenly can become processed by the offloading hw
units. Because UDP ports only form a contract between the end points and
not with the router in between it would be illegal to treat those not
locally designated packets as vxlan by the router.

Also multicast traffic is always scoped, so the flow has to include the
ifindex at least to allow differentiation between different scopes.

Bye,
Hannes