On 2018/9/13 20:44, Eric Dumazet wrote:

On Thu, Sep 13, 2018 at 5:32 AM Greg KH [off-list ref] wrote:

quoted

On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:

quoted

On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:

quoted

On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:

quoted

On 2018/8/16 19:39, Michal Kubecek wrote:

quoted

I suspect you may be doing something wrong with your tests. I checked
the segmentsmack testcase and the CPU utilization on receiving side
(with sending 10 times as many packets as default) went down from ~100%
to ~3% even when comparing what is in stable 4.4 now against older 4.4
kernel.

There seems no obvious problem when you send packets with default
parameter in Segmentsmack POC, Which is also very related with your
server's hardware configuration. Please try with below parameter to
form OFO packets

I did and even with these (questionable, see below) changes, I did not
get more than 10% (of one core) by receiving ksoftirqd.

quoted

      for (i = 0; i < 1024; i++)      // 128->1024

...

quoted

      usleep(10*1000); // Adjust this and packet count to match the target!, sleep 100ms->10ms

The comment in the testcase source suggests to do _one_ of these two
changes so that you generate 10 times as many packets as the original
testcase. You did both so that you end up sending 102400 packets per
second. With 55 byte long packets, this kind of attack requires at least
5.5 MB/s (44 Mb/s) of throughput. This is no longer a "low packet rate
DoS", I'm afraid.

Anyway, even at this rate, I only get ~10% of one core (Intel E5-2697).

What I can see, though, is that with current stable 4.4 code, modified
testcase which sends something like

  2:3, 3:4, ..., 3001:3002, 3003:3004, 3004:3005, ... 6001:6002, ...

I quickly eat 6 MB of memory for receive queue of one socket while
earlier 4.4 kernels only take 200-300 KB. I didn't test latest 4.4 with
Takashi's follow-up yet but I'm pretty sure it will help while
preserving nice performance when using the original segmentsmack
testcase (with increased packet ratio).

Ok, for now I've applied Takashi's fix to the 4.4 stable queue and will
push out a new 4.4-rc later tonight.  Can everyone standardize on that
and test and let me know if it does, or does not, fix the reported
issues?

If not, we can go from there and evaluate this much larger patch series.
But let's try the simple thing first.

So, is the issue still present on the latest 4.4 release?  Has anyone
tested it?  If not, I'm more than willing to look at backported patches,
but I want to ensure that they really are needed here.

thanks,

Honestly, TCP stack without rb-tree for the OOO queue is vulnerable,
even with non malicious sender,
but with big enough TCP receive window and a not favorable network.

So a malicious peer can definitely send packets needed to make TCP
stack behave in O(N), which is pretty bad if N is big...

9f5afeae51526b3ad7b7cb21ee8b145ce6ea7a7a ("tcp: use an RB tree for ooo
receive queue")
was proven to be almost bug free [1], and should be backported if possible.

[1] bug fixed :
76f0dcbb5ae1a7c3dbeec13dd98233b8e6b0b32a tcp: fix a stale ooo_last_skb
after a replace

Thank you for Eric's suggestion, I will do some work to backport them.

.