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  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:	Fri, 12 Feb 2016 16:59:01 +0000
From:	Paul Durrant <>
To:	David Miller <>
CC:	"" <>,
	"" <>
Subject: RE: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

> -----Original Message-----
> From: David Miller []
> Sent: 12 February 2016 16:42
> To: Paul Durrant
> Cc:;
> Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
> From: Paul Durrant <>
> 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.
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.


Powered by blists - more mailing lists