linux-kernel - Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

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: <1729915.dWWxddREcQ@stwm.de>
Date:   Thu, 04 Oct 2018 15:57:52 +0200
From:   Wolfgang Walter <linux@...m.de>
To:     Florian Westphal <fw@...len.de>
Cc:     Steffen Klassert <steffen.klassert@...unet.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        christophe.gouault@...nd.com
Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

Am Dienstag, 2. Oktober 2018, 23:35:36 schrieb Florian Westphal:
> Wolfgang Walter <linux@...m.de> wrote:
> > Am Dienstag, 2. Oktober 2018, 16:56:16 schrieb Florian Westphal:
> > > I'm experimenting with per-dst inexact lists in an rbtree but
> > > this will take time.
> > 
> > Hmm, I doubt that this is worth the effort. And certainly not that easy
> 
> Well, I'm not going to send a revert of the flowcache removal.
> 
> I'm willing to experiment with alternatives to a full iteration of the
> inexact list but thats it.

If this brings performance back to pre-removal, I'm fine with that. I'm even 
fine if it is slower by a factor of 2.

I think it is a serious regression, and there is no workaround, and therefor 
it cannot stay like that.

So I still hope that reverting is an option if no acceptable solution can be 
found.

> 
> > correctly done, as it still would have to obey the original order of the
> > rules (their priority).
> 
> Except that neither the priority or the order in which it was added
> matters in case the selector doesn't match.

To match a packet one has to find all matching rules and chose that one with 
the lowest priority.

"indexing" by dst will not help much if you have a ruleset where a lot of 
rules sharing a dst. You also have to replicate rules with dsts that have a 
prefix oft another dst as they may habe a higher priority even if they are 
less specific.

Every such entry may again have such an "indexing" by dst. Only then this 
would be efficient.

> 
> I see no reason why we can't have inexact lists done per dst<->src pairs.
> 
> > You may have a lot of rules of the form say
> > 
> > 	10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....
> > 	10.0.0.0/16 <=> 10.1.0.8/29 encrypt ....
> 

<=> means (in the forwarding case) that the rule set contains the inverted 
rule (at least if you use it in usually ways). So 

	10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....

means

	10.0.0.0/16 => 10.1.0.0/29
	10.1.0.0/29 => 10.0.0.0/16

> Sure.
> 
> > Also, you get something like that
> > 
> > 	10.0.1.0/24 <=> 10.0.2.0/29 allow
> > 	10.0.0.0/16 <=> 10.0.2.0/24 encrypt
> > 	0.0.0.0 <=> 10.0.2.0/16 block
> > 
> > And people may use source port and/or destination port or protocol
> > (tcp/udp/imcp) to further tailor there ruleset.
> 
> Yes. 0.0.0.0/0 handling will require some extra consideration.
> 

There may also be rulesets like

	10.0.1.0/24 => 10.1.0.0/29 encrypt X
	10.0.0.0/16 => 10.1.0.0/29 encrypt Y

Or

	10.0.0.0/16 *  => 10.1.0.0/24 80 encrypt Y
	10.0.1.0/24 * => 10.1.0.0/17 * encrypt X
	10.0.0.0/16 *  => 10.1.0.0/20 * encrypt Z

> So far I have not seen a show-stopper however.

I wonder why there is no such thing for netfilter or the rules list in 
routing. nf does not have such a thing, either. This is the reason why I think 
that this is not that easy and for longterm kernel 4.14 the best solution will 
be a revert anyway.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts