netdev - Re: [net-next 08/15] net/mlx5e: CT: Preparation for offloading +trk+new ct rules

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: <20210122021618.GH3863@horizon.localdomain>
Date:   Thu, 21 Jan 2021 23:16:18 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Oz Shlomo <ozsh@...dia.com>, Roi Dayan <roid@...dia.com>,
        Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Paul Blakey <paulb@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next 08/15] net/mlx5e: CT: Preparation for offloading
 +trk+new ct rules

On Fri, Jan 22, 2021 at 02:18:34AM +0100, Pablo Neira Ayuso wrote:
> Hi Oz,
> 
> On Wed, Jan 20, 2021 at 06:09:48PM +0200, Oz Shlomo wrote:
> > On 1/14/2021 11:50 PM, Marcelo Ricardo Leitner wrote:
> > > 
> > > Thoughts?
> > > 
> > 
> > I wonder if we should develop a generic mechanism to optimize CT software
> > for a use case that is faulty by design.
> > This has limited value for software as it would only reduce the conntrack
> > table size (packet classification is still required).
> > However, this feature may have a big impact on hardware offload.
> > Normally hardware offload relies on software to handle new connections.
> > Causing all new connections to be processed by software.
> > With this patch the hardware may autonomously set the +new connection state
> > for the relevant connections.
> 
> Could you fix this issue with unidirectional flows by checking for
> IPS_CONFIRMED status bit? The idea is to hardware offload the entry
> after the first packet goes through software successfully. Then, there
> is no need to wait for the established state that requires to see
> traffic in both directions.

That's an interesting idea. This way, basically all that needs to be
changed is tcf_ct_flow_table_process_conn() to handle this new
condition for UDP packets and on tcf_ct_act().

It has a small performance penaulty if compared to the original
solution, as now the first packet(s) goes to sw, but looks like a good
compromise between supporting a (from what I could understand)
somewhat lazy flow design (as I still think these didn't need to go
through conntrack), an uniform system behavior (with and without
offload, with mlx5 or another driver) and a more generic approach.
Other situations that rely on unidirectional UDP flows will benefit
from it as well.

This way I even think it doesn't need to be configurable right now.
It will be easier to add a knob to switch back to the old behavior if
needed later on, if anything.

  Marcelo