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: <20180312.145843.1054152977291695095.davem@davemloft.net>
Date:   Mon, 12 Mar 2018 14:58:43 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     pablo@...filter.org
Cc:     netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 00/30] Netfilter/IPVS updates for net-next

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.

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.

If you are targetting one specific piece of hardware with TCAMs
that you are familiar with.  I'd like you to stop right there.
Because if that is all that this infrastructure can actually
be used for, it is definitely designed wrong.

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.

No other area of networking puts the cart before the horse like this.

I do not agree at all with the flow table infrastructure and I
therefore do not want to pull any more flow table changes into my tree
until there is an actual user of this stuff in that pull request which
actually works in a way which is useful for people.  It is completely
dead and useless code currently.

If you disagree you have to not just say it, but show it with a driver
that successfully and cleanly uses this code to offload conntrack.

Meanwhile, remove the flow table commits from this pull request out of
your tree and ask me to pull in the rest.

Thanks.