netdev - Re: [PATCH net-next v2 2/2] tcp_diag: report TCP MD5 signing keys and addresses

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]

Message-ID: <1503752927.11498.34.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Sat, 26 Aug 2017 06:08:47 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Ivan Delalande <colona@...sta.com>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/2] tcp_diag: report TCP MD5 signing keys
 and addresses

On Sat, 2017-08-26 at 07:53 +0200, Ivan Delalande wrote:

> 
> Sorry, I probably should have detailed my changes. I tried to address
> this by locking the whole socket in the caller, tcp_diag_get_aux, just
> outside of the rcu_read_lock. Would this work here, or do you see a
> better way?
> 

locking the socket is problematic.

It is already done in tcp_get_info() since linux-4.10 and unfortunately
it added unreasonable stall when a socket is flooded with tiny SACK
messages (socket backlog is huge)

People are now making tcp_rmem and tcp_wmem much bigger to allow BBR
flows to reach line rate on very long distance communications.

We are working to make tcp_rack_mark_lost() not having O(N) behavior,
but it is not done yet.

I would stick to RCU, but add sanity checks, so that _if_ the list is
different on the second RCU list traversal, you make sure :

1) We do not try to put more data in the reserved space

2) We memset(ptr, 0, remaining) the remaining space if we found less
entries in the 2nd loop.