netdev - Re: [PATCH net-next] selftests/net: ignore background traffic in psock

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: <20180223.124802.1669012463834833697.davem@davemloft.net>
Date:   Fri, 23 Feb 2018 12:48:02 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     willemdebruijn.kernel@...il.com
Cc:     netdev@...r.kernel.org, maloneykernel@...il.com, willemb@...gle.com
Subject: Re: [PATCH net-next] selftests/net: ignore background traffic in
 psock_fanout

From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Date: Fri, 23 Feb 2018 11:56:20 -0500

> From: Willem de Bruijn <willemb@...gle.com>
> 
> The packet fanout test generates UDP traffic and reads this with
> a pair of packet sockets, testing the various fanout algorithms.
> 
> Avoid non-determinism from reading unrelated background traffic.
> Fanout decisions are made before unrelated packets can be dropped with
> a filter, so that is an insufficient strategy [*]. Run the packet
> socket tests in a network namespace, similar to msg_zerocopy.
> 
> It it still good practice to install a filter on a packet socket
> before accepting traffic. Because this is example code, demonstrate
> that pattern. Open the socket initially bound to no protocol, install
> a filter, and only then bind to ETH_P_IP.
> 
> Another source of non-determinism is hash collisions in FANOUT_HASH.
> The hash function used to select a socket in the fanout group includes
> the pseudorandom number hashrnd, which is not visible from userspace.
> To work around this, the test tries to find a pair of UDP source ports
> that do not collide. It gives up too soon (5 times, every 32 runs) and
> output is confusing. Increase tries to 20 and revise the error msg.
> 
> [*] another approach would be to add a third socket to the fanout
>     group and direct all unexpected traffic here. This is possible
>     only when reimplementing methods like RR or HASH alongside this
>     extra catch-all bucket, using the BPF fanout method.
> 
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>

Applied, thanks Willem.

Indeed, not being able to control hashrnd makes determinism in tests
like this quite difficult.