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

Date:   Fri, 26 Oct 2018 14:18:58 +0200
From:   Wolfgang Walter <linux@...m.de>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, fw@...len.de, steffen.klassert@...unet.com,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        christophe.gouault@...nd.com, gregkh@...uxfoundation.org
Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

Am Donnerstag, 25. Oktober 2018, 10:34:50 schrieb David Miller:
> From: Wolfgang Walter <linux@...m.de>
> Date: Thu, 25 Oct 2018 11:38:19 +0200
> 
> > there is now a new 4.19 which still has the big performance regression
> > when
> > many ipsec tunnels are configured (throughput and latency get worse by 10
> > to 50 times) which makes any kernel > 4.9 unusable for our routers.
> > 
> > I still don't understand why a revert of the flow cache removal at least
> > for the longterm kernels is that a bad option (maybe as a compile time
> > option), especially as there is no workaround available.
> 
> You do know that the flow cache is DDoS targettable, right?
> 
> That's why we removed it, we did not make the change lightly.

Though this is true, we now have simply a permanent DDoS situation. The 
removal of the flow cache leads to the situation so that with enough ipsec-
tunnels you are now always as bad as you would have been prior under a DDoS 
attack.

This is not comparable to the routing cache situation where a fast, well 
tested solution already existed (for routes in a table; if you use a lot of 
rules for policy routing this may be a different story).

Futher I don't think that the DoS is that a strong argument for the removal of 
the routing cache if the routing performance would have dropped 10 times and 
more.

Also, the routing cache was even a problem with legitimate traffic, so I never 
had a problem with the moderate performance regression it caused here.

> 
> Adding a DDoS vector back into the kernel is not an option sorry.

All kernels >= 4.14 are in our use case as bad as if they were under attack. 
They are completely unusable and I even can't 

> 
> Please work diligently with Florian and others to try and find ways to
> soften the performance hit.
> 

I proposed to revert this for the longterm kernels and I only depending on a 
compile time option which explicitely had to be switched on. Then we could 
start using 4.19. People not using ipsec or who use it only with < 100 rules 
would still live without flow cache.

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