netdev - Re: [RFC net-next] net/sched: act_mirred: allow mirred ingress through networking backlog

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] [day] [month] [year] [list]

Message-ID: <Y2QSi5CIkwLtEfm1@pop-os.localdomain>
Date:   Thu, 3 Nov 2022 12:12:11 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Davide Caratti <dcaratti@...hat.com>
Cc:     jhs@...atatu.com, jiri@...nulli.us, marcelo.leitner@...il.com,
        netdev@...r.kernel.org, pabeni@...hat.com, wizhao@...hat.com,
        peilin.ye@...edance.com
Subject: Re: [RFC net-next] net/sched: act_mirred: allow mirred ingress
 through networking backlog

On Mon, Oct 31, 2022 at 10:44:26PM +0100, Davide Caratti wrote:
> using TC mirrred in the ingress direction, packets are passed directly
> to the receiver in the same context. There are a couple of reasons that
> justify the proposal to use kernel networking backlog instead:
> 
> a) avoid the soft lockup observed with TCP when it sends data+ack after
>    receiving packets through mirred (William sees them using OVS,
>    something similar can be obtained with a kselftest [1)]

Do you have a pointer to the original bug report? The test case you
crafted looks unreal to me, a TCP socket sending packets to itself does
not look real.


> b) avoid packet drops caused by mirred hitting MIRRED_RECURSION_LIMIT
>    in the above scenario
> 
> however, like Cong pointed out [2], we can't just change mirred redirect to
> use the networking backlog: this would break users expectation, because it
> would be impossible to know the RX status after a packet has been enqueued
> to the backlog.
> 
> A possible approach can be to extend the current set of TC mirred "eaction",
> so that the application can choose to use the backlog instead of the classic
> ingress redirect. This would also ease future decisions of performing a
> complete scrub of the skb metadata for those packets, without changing the
> behavior of existing TC ingress redirect rules.
> 

>From users' point of view, why do we need to care about this
implemention detail when picking TC mirred action?


Thanks.