netdev - RE: [PATCH net-next] store complete hash type information in socket buffer...

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: <de5bb6116dde4a288838e8ef5978c8d1@AMSPEX02CL03.citrite.net>
Date:	Fri, 19 Feb 2016 08:55:20 +0000
From:	Paul Durrant <Paul.Durrant@...rix.com>
To:	Tom Herbert <tom@...bertland.com>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Jay Vosburgh <j.vosburgh@...il.com>,
	"Veaceslav Falico" <vfalico@...il.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: RE: [PATCH net-next] store complete hash type information in socket
 buffer...

> -----Original Message-----
> From: Tom Herbert [mailto:tom@...bertland.com]
> Sent: 19 February 2016 02:22
> To: Eric Dumazet
> Cc: David Miller; Paul Durrant; Linux Kernel Network Developers; Jay
> Vosburgh; Veaceslav Falico; Andy Gospodarek
> Subject: Re: [PATCH net-next] store complete hash type information in
> socket buffer...
> 
> On Wed, Feb 17, 2016 at 1:30 PM, Eric Dumazet <eric.dumazet@...il.com>
> wrote:
> > On mer., 2016-02-17 at 15:44 -0500, David Miller wrote:
> >> From: Paul Durrant <paul.durrant@...rix.com>
> >> Date: Mon, 15 Feb 2016 08:32:08 +0000
> >>
> >> > ...rather than a boolean merely indicating a canonical L4 hash.
> >> >
> >> > skb_set_hash() takes a hash type (from enum pkt_hash_types) as an
> >> > argument but information is lost since only a single bit in the skb
> >> > stores whether that hash type is PKT_HASH_TYPE_L4 or not. By using
> >> > two bits it's possible to store the complete hash type information.
> >> >
> >> > Signed-off-by: Paul Durrant <paul.durrant@...rix.com>
> >>
> >> Tom and/or Eric, please have a look at this.
> >
> > I guess my question is simply 'why do we need this' ?
> >
> > Consuming a bit in our precious sk_buff is not something we want for
> > some obscure feature.
> >
> Right. I think the reason Paul wants this is be able to pass the hash
> to a Windows guest. As I pointed out though, we'd also need an
> indication that the hash is Toeplitz to be really correct with Windows
> interface.

Tom,

  Actually xen-netback can live without this change. Windows (at the moment at least) only cares about L3 and L4 hashes. The motivation for this change was just to fix the apparent mismatch where some functions deal with the hash type enum and some the single 'is l4' bit. I agree it would also be useful and sensible for sk_buff to also encode a hash algorithm as most NIC h/w out there will probably use Toeplitz (since it's a hard requirement for Windows) but may also be able use alternative hashes.

> The Linux driver interface does allow indicating L2, L3, or
> L4 hash with the assumption that differentiation might be useful some
> day, but so far it only appears that distinguishing L4 from others has
> any value. It would be interesting to know if Windows actually does
> anything useful in differentiating L2 and L3 hashes.
> 

  As I said above, it does not distinguish L2 and L3 at the moment so this patch is not necessary. I still think it’s a step in the right direction though.

  Cheers,

    Paul

> Tom
> 
> >
> >