netdev - Re: [PATCH v2 net-next 0/4] sfc: encapsulated filters

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: <848d3b88-7e6e-4b9e-ba68-967aa45e9552@solarflare.com>
Date:   Tue, 31 Jan 2017 11:42:44 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Tom Herbert <tom@...bertland.com>
CC:     <linux-net-drivers@...arflare.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 0/4] sfc: encapsulated filters

On 27/01/17 18:03, Tom Herbert wrote:
> On Fri, Jan 27, 2017 at 7:00 AM, Edward Cree <ecree@...arflare.com> wrote:
>> This series adds support for setting up filters for encapsulated traffic on
>> SFC 8000-series adapters, which recognise VXLAN, GENEVE and NVGRE packets by
>> parsing packet headers.  (VXLAN and GENEVE will only be recognised if the
>> driver on the primary PF has notified the firmware of relevant UDP ports,
>> which this driver does not yet do.)
>> While the driver currently has no way of using these filters for flow
>> steering, it is nonetheless necessary to insert catch-all (aka 'default')
>> filters to direct this traffic, similar to the existing unencapsulated uni-
>> and multi-cast catch-all filters, as otherwise the traffic will be dropped
>> by the NIC - implementation details of the hardware filtering mean that the
>> traffic will not get matched on outer MAC address to unencapsulated catch-
>> all filters.  (Yes, this is a mess.)
> I don't understand this. You seem to be saying that unless there is
> filtering for VXLAN and GENEVE these packets will dropped. These are
> _just_ UDP packets. Anything that the NIC does special for them is at
> most an optimization, it can *NEVER* be a requirement for NICs to be
> able to parse these protocols. Please elaborate...
>
> Tom
Unless the NIC has been told to consider a particular UDP port as either VXLAN
or GENEVE, it _will_ treat it as "_just_ UDP packets" and go through the normal
filtering.  It's only NVGRE that (without this series) gets dropped.
Both before and after this series, the NIC's list of encapsulation UDP ports is
not set up and is thus empty, so it treats all UDP traffic normally.  In the
future, this list will be populated by the driver (in order to support inner-
frame CHECKSUM_UNNECESSARY offload), and the traffic thereby designated as
encapsulated will hit the inner-frame filters (which this series sets up).

-Ed