netdev - Re: [PATCH 6/7] mlx4_en: Adding rxhash support

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:	Tue, 18 Oct 2011 20:35:00 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Yevgeny Petrilin <yevgenyp@...lanox.co.il>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 6/7] mlx4_en: Adding rxhash support

On Tue, 2011-10-18 at 08:36 -0700, Stephen Hemminger wrote:
> On Tue, 18 Oct 2011 08:59:44 +0000
> Yevgeny Petrilin <yevgenyp@...lanox.co.il> wrote:
> 
> > > 
> > > What is the gain using random values ?
> > > 
> > > Usually, we tend to have same hardware in a single machine, or we use
> > > active-backup bonding mode, and an active slave flip can change rxhash
> > > values with litle effect, since this happens not often.
> > > 
> > > I really prefer not random values, because it allows to have replayable
> > > configurations : For a given tcp flow, the same rxhash value is given
> > > and same cpu target in RPS. Its way easier to tune your machine for some workloads.
> > > 
> > 
> > There is no gain in random values, 
> > I'll make the change to have static value for RSS function.
> > 
> > We might consider how to ensure consistency across the different drivers in this aspect.
> 
> The key should be part of the network device core. Almost all hardware just
> implements the Microsoft standard, and if all drivers used same key they should
> come up with the same hash.

It should, but that's not enough.  The core also needs to be responsible
for initialising the hash indirection table, determining how many RX
queues to create, and IRQ affinity hints.

> Although using the same key all the time makes testing easier.
> The risk of using the same key is that it makes it easier for an attacker to
> create a set of addresses that all map to the same CPU which would make a DoS
> attack work better.  Therefore the key should be randomly generated at boot time.

If I understand correctly, the core of the Toeplitz hash functions is
(pretending we have a wide enough type called bigint):

u32 toeplitz_hash(bigint input, bigint key, unsigned width)
{
	u32 hash = 0;
	unsigned i;

	for (i = 0; i < width; i++)
		if (input & ((bigint)1 << i))
		        hash ^= key >> (1 + i);
	return hash;
}

This is hardly a cryptographic hash!  And while the key probably should
be random it should not just be random *bits*.  For example, if any 32
consecutive bits of the key are zero then 1 bit of input will have no
effect on the hash at all.

There was also a proposal a while back that we should try to make the
hash symmetric w.r.t. RX and TX addresses, so that both directions of a
flow through a router/bridge are aligned.  I think this was to be done
by repeating a 16-bit pattern across the key.  Not sure whether that's
worthwhile.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html