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: <CALx6S36ztVKytRo615kkYbvpwhUYnEcb3tCLmeBfxmmvcr7huw@mail.gmail.com>
Date:   Tue, 31 Jan 2017 09:38:37 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Edward Cree <ecree@...arflare.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 Tue, Jan 31, 2017 at 3:42 AM, Edward Cree <ecree@...arflare.com> wrote:
> 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.

That doesn't sound much better. NICs have no business to drop any
properly formed IP packet for any IP protocol as a default behavior.
If packets should be dropped that should only be configured by the
user.

> 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