netdev - Re: [PATCH bpf-next 0/7] bpf: Propagate cn to 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:   Mon, 25 Mar 2019 01:48:27 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     brakmo <brakmo@...com>, netdev <netdev@...r.kernel.org>,
        Martin Lau <kafai@...com>, Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP

On 03/25/2019 01:33 AM, Eric Dumazet wrote:
> 
> 
> On 03/24/2019 09:19 AM, Alexei Starovoitov wrote:

>> Cover letter also explains why bpf_skb_ecn_set_ce is not enough.
>> Please realize that existing qdiscs already doing this.
>> The patchset allows bpf-cgroup to do the same.
> 
> Not the same thing I am afraid.

To be clear Alexei :

Existing qdisc set CE mark on a packet, exactly like a router would do.
Simple and universal.
This can be stacked, and done far away from the sender.

We do not _call_ back local TCP to propagate cn.

We simply rely on the fact that incoming ACK will carry the needed information,
and TCP stack already handles the case just fine.

Larry cover letter does not really explain why we need to handle a corner case
(local drops) with such intrusive changes.

TCP Small Queues already should make sure local drops are non existent.