netdev - Re: [PATCH 00/30] Netfilter/IPVS updates for net-next

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: <d8eec20f-5580-d7c7-860b-14953b55809d@mellanox.com>
Date:   Fri, 16 Mar 2018 18:39:03 +0200
From:   Guy Shattah <sguy@...lanox.com>
To:     David Miller <davem@...emloft.net>, pablo@...filter.org
Cc:     netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 00/30] Netfilter/IPVS updates for net-next



On 12/03/2018 20:58, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@...filter.org>
> Date: Mon, 12 Mar 2018 18:58:50 +0100
>
>> The following patchset contains Netfilter/IPVS updates for your net-next
>> tree. This batch comes with more input sanitization for xtables to
>> address bug reports from fuzzers, preparation works to the flowtable
>> infrastructure and assorted updates. In no particular order, they are:
> Sorry, I've seen enough.  I'm not pulling this.
>
> What is the story with this flow table stuff?  I tried to ask you
> about this before, but the response I was given was extremely vague
> and did not answer my question at all.
>
> This is a lot of code, and a lot of infrastructure, yet I see
> no device using the infrastructure to offload conntack.
Hi David,

Pablo's code is a very welcome addition to the flow tables infrastructure.
We at Mellanox already have customers asking for Offload of Connection 
Tracking.
While a complete hardware implementation is yet to arrive. Pablo's 
contribution is blessed.

Using this infrastructure we are capable of completely offloading 
connection tracking (Without TCP window validation)
and possibly do a complete offload once hardware support for TCP window 
Validation shows up.

I'm currently working closely with Pablo to create the first driver 
implementation to utilize
hardware offloading. Needless to say - prior to having hardware 
implementation a software infrastructure is required.
> Nor can I see how this can possibly be even useful for such an
> application.  What conntrack offload needs are things completely
> outside of what the flow table stuff provides.  Mainly, they
> require that the SKB is completely abstracted away from all of
> the contrack code paths, and that the conntrack infrastructure
> operates on an abstract packet metadata concept.
Assuming that the software maintains the flow in the system,
it is reasonable to allow software do the connection establishment and 
termination
and let the hardware do all the rest between (again - without TCP window 
validation, unless a specialized hardware exists)

>
> This, as has been the case in the past, is what is wrong with
> netfilter approach to supporting offloading.  We see all of this
> infrastructure before an actual working use case is provided for a
> specific piece of hardware for a specific driver in the tree.
>
> Nobody can evaluate whether the approach is good or not without
> a clear driver change implementing support for it.
I'm speaking on behalf of Mellanox.
Would one driver support as demonstration suffice?

Thanks,

Guy