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: <eacbd4b8-b8dc-4402-9cbe-666c1ae112e2@gmail.com>
Date: Wed, 19 Mar 2025 20:37:27 +0100
From: Eric Woudstra <ericwouds@...il.com>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Michal Ostrowski <mostrows@...thlink.net>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Jozsef Kadlecsik <kadlec@...filter.org>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
 linux-hardening@...r.kernel.org, Nikolay Aleksandrov <razor@...ckwall.org>
Subject: Re: [PATCH v10 nf-next 2/3] netfilter: nf_flow_table_offload: Add
 nf_flow_encap_push() for xmit direct



On 3/19/25 12:23 AM, Pablo Neira Ayuso wrote:
> On Sat, Mar 15, 2025 at 08:59:09PM +0100, Eric Woudstra wrote:
>> Loosely based on wenxu's patches:
>>
>> "nf_flow_table_offload: offload the vlan/PPPoE encap in the flowtable".
> 
> I remember that patch.
> 
>> Fixed double vlan and pppoe packets, almost entirely rewriting the patch.
>>
>> After this patch, it is possible to transmit packets in the fastpath with
>> outgoing encaps, without using vlan- and/or pppoe-devices.
>>
>> This makes it possible to use more different kinds of network setups.
>> For example, when bridge tagging is used to egress vlan tagged
>> packets using the forward fastpath. Another example is passing 802.1q
>> tagged packets through a bridge using the bridge fastpath.
>>
>> This also makes the software fastpath process more similar to the
>> hardware offloaded fastpath process, where encaps are also pushed.
> 
> I am not convinced that making the software flowtable more similar
> hardware is the way the go, we already have to deal with issues with
> flow teardown mechanism (races) to make it more suitable for hardware
> offload.
> 
> I think the benefit for pppoe is that packets do not go to userspace
> anymore, but probably pppoe driver can be modified push the header
> itself?
> 
> As for vlan, this is saving an indirection?
> 
> Going in this direction means the flowtable datapath will get more
> headers to be pushed in this path in the future, eg. mpls.
> 
> Is this also possibly breaking existing setups? eg. xfrm + vlan
> devices, but maybe I'm wrong.
> 

If you do not want to touch the software fastpath, It should be possible
to do it without.

For bridged interfaces, only use the hardware fastpath, not installing a
hook for the software fastpath at all.

Another option is installing the hook (matching the hash, updating
counter and perhaps calling flow_offload_refresh() and so), but then
letting traffic continue the normal path. That is, until the hardware
offload takes over.

In both cases only allow to add the flowtable if the offload flag is set.

What do you think?

But in all cases (including existing cases in existing code), I think we
need the patches from "[PATCH v10 nf-next 0/3] netfilter: fastpath fixes".

Could you look at these?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ