netdev - Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

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:	Sun, 14 Feb 2016 23:01:43 +0100
From:	Tom Herbert <tom@...bertland.com>
To:	Paul Durrant <Paul.Durrant@...rix.com>
Cc:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

On Fri, Feb 12, 2016 at 5:59 PM, Paul Durrant <Paul.Durrant@...rix.com> wrote:
>> -----Original Message-----
>> From: David Miller [mailto:davem@...emloft.net]
>> Sent: 12 February 2016 16:42
>> To: Paul Durrant
>> Cc: netdev@...r.kernel.org; xen-devel@...ts.xenproject.org
>> Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
>>
>> From: Paul Durrant <Paul.Durrant@...rix.com>
>> Date: Fri, 12 Feb 2016 11:07:50 +0000
>>
>> > Windows *requires* use of Teoplitz so your position completely rules
>> > out being able to support receive side scaling in Windows PV
>> > frontends on Linux kernel backends, not only for Xen but for any
>> > other hypervisor, which I think is totally unreasonable.
>>
>> We have strong reason to believe that Toeplitz has properties that
>> make it very weak if not exploitable, therefore doing software RSS
>> with Jenkins is superior.
>
> I don't disagree, but there is really no choice of algorithm where a Windows frontend is concerned. My patches only add Toeplitz hashing into xen-netback according to the specification in xen's netif.h; the algorithm is not exposed for use by any other part of the kernel.

You are touching struct sk_buff for this. Changing such a core
networking data structure just to satisfy a requirement of Windows
seems like a long shot to me...

> If it would help I can add a module parameter to xen-netback to control advertising the option of the hash to frontends so that it can be globally disabled if it is deployed on host where there are no Windows guests.

Toeplitz is dog-slow to compute in software. Comparing your
implementation to Jenkins hash (hash) it's about 12x slower (102 nsecs
versus 8 nsecs for IPv4 on my system). Doing this for every packet
seems like a non-starter to me. I suspect the majority use case for
receive is simple uniform load balancing across the virtual queues in
which case jhash will be perfectly fine. The case where it probably
matters is if the Windows OS is trying to configure some non-uniform
distribution (isolating a single flow for instance). To handle this
case, you could implement a simple look up flow table to map a
skb->hash to a Toeplitz hash, so that the Toeplitz hash only needs to
be calculated one time for a flow (recomputed with some periodic
timeout). This would be probabilistic though, so if really Windows
requires the hash to be set correctly 100% of the time it won't work.

Tom

>
>   Paul