netdev - Re: [PATCH net-next,v3 0/9] netfilter: flowtable bridge and vlan enhancements

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]

Date:   Sat, 21 Nov 2020 19:56:21 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>,
        netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, razor@...ckwall.org, jeremy@...zel.net
Subject: Re: [PATCH net-next,v3 0/9] netfilter: flowtable bridge and vlan
 enhancements

On Sat, Nov 21, 2020 at 10:15:51AM -0800, Jakub Kicinski wrote:
> On Sat, 21 Nov 2020 13:31:38 +0100 Pablo Neira Ayuso wrote:
> > On Mon, Nov 16, 2020 at 11:56:58PM +0100, Pablo Neira Ayuso wrote:
> > > On Mon, Nov 16, 2020 at 02:45:21PM -0800, Jakub Kicinski wrote:  
> > > > On Mon, 16 Nov 2020 23:36:15 +0100 Pablo Neira Ayuso wrote:  
[...]
> > I have been discussing the topology update by tracking fdb updates
> > with the bridge maintainer, I'll be exploring extensions to the
> > existing fdb_notify() infrastructure to deal with this scenario you
> > describe. On my side this topology update scenario is not a priority
> > to be supported in this patchset, but it's feasible to support it
> > later on.
> 
> My concern is that invalidation is _the_ hard part of creating caches.
> And I feel like merging this as is would be setting our standards pretty
> low. 

Interesting, let's summarize a bit to make sure we're on the same
page:

- This "cache" is optional, you enable it on demand through ruleset.
- This "cache" is configurable, you can specify through ruleset policy
  what policies get into the cache and _when_ they are placed in the
  cache.
- This is not affecting any existing default configuration, neither
  Linux networking not even classic path Netfilter configurations,
  it's a rather new thing.
- This is showing performance improvement of ~50% with a very simple
  testbed. With pktgen, back few years ago I was reaching x2.5
  performance boost in software in a pktgen testbed.
- This is adding minimal changes to netdev_ops, just a single
  callback.

For the live VM migration you describe, connections might time out,
but there are many use-cases where this is still valid, some of them
has been described already here.

> Please gather some review tags from senior netdev developers. I don't
> feel confident enough to apply this as 100% my own decision.

Fair enough.

This requirement for very specific Netfilter infrastructure which does
not affect any other Networking subsystem sounds new to me.

What senior developers specifically you would like I should poke to
get an acknowledgement on this to get this accepted of your
preference?

Thank you.