netdev - Re: [PATCH v3 net 0/5] tcp: fixes to non-SACK TCP

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:   Tue, 13 Mar 2018 06:43:23 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:     netdev <netdev@...r.kernel.org>, Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Subject: Re: [PATCH v3 net 0/5] tcp: fixes to non-SACK TCP

On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen
<ilpo.jarvinen@...sinki.fi> wrote:
> Here is a series of fixes to issues that occur when SACK is not
> enabled for a TCP connection. These are not fixes to just some
> remote corner cases of recovery but many/almost all recoveries
> without SACK will be impacted by one (or even more than one) of
> them. The sender-side changes (1-4) are not mainly, if any, to
> improve performance (throughput) but address correctness
> (congestion control responses should not get incorrectly
> reverted) and burstiness (that may cause additional problems
> later as some of the packets in such bursts may get dropped
> needing again to resort to loss recovery that is likely
> similarly bursty).

GRO (or similar) adoption a long time ago (not only by linux) had a
serious impact on non SACK flow.
Should we also disable GRO by default ?
(my answer is no, just in case someone wonders)

I am sorry, but I am  still not convinced by your patches, trying to
give a wrong incentive to people keeping their prehistoric stacks,
that have serious problems on wifi anyway, and or middle boxes
"aggregating/compressing ACKS"

The last patch is particularly problematic in my opinion, you have not
provided  packetdrill tests to prove there was no danger.

It seems you leave to us the task of dealing with possible issues,
only added a bold changelog.

Since the bugs you claim to fix are at least 10 years old, and your
fixes are far from being trivial,
please wait our packetdrill regression tests being published.
This should happen in less than one month I believe, in time for linux-4.17

Note that the publication of the updated packetdrill and test suite is
not an easy task,
since we accumulated a lot of hacks both in kernel to cope with timer
slacks and in packetdrill
for various experimental or private features that are not yet in
upstream kernels.

So we are cleaning all this, and will be happy to help you if you need.

Thanks.