netdev - Re: [PATCH net-next] tcp: add optional per socket transmit delay

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: <20190611.121601.1611337978166305865.davem@davemloft.net>
Date:   Tue, 11 Jun 2019 12:16:01 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     edumazet@...gle.com
Cc:     netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next] tcp: add optional per socket transmit delay

From: Eric Dumazet <edumazet@...gle.com>
Date: Mon, 10 Jun 2019 20:03:34 -0700

> This patchs adds TCP_TX_DELAY socket option, to set a delay in
> usec units.
> 
>   unsigned int tx_delay = 10000; /* 10 msec */
> 
>   setsockopt(fd, SOL_TCP, TCP_TX_DELAY, &tx_delay, sizeof(tx_delay));

I'm trying to think about what the implications are for allowing
arbitrary users to do this.

It allows a user to stuff a TCP cloned SKB in the queues for a certain
amount of time, and then multiply this by how big a send window the
user can create (this ramp up takes no time, as the TCP_TX_DELAY
option can be intentionally set only after the window is maxxed out)
and how many TCP flows the user can create.

Is this something worth considering?