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 11:49:19 -0700
From:	Jesse Brandeburg <jesse.brandeburg@...il.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, Oct 18, 2011 at 8:36 AM, Stephen Hemminger
<shemminger@...tta.com> wrote:
> On Tue, 18 Oct 2011 08:59:44 +0000
> Yevgeny Petrilin <yevgenyp@...lanox.co.il> wrote:
>> 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.
>
> 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.

Stephen, I respectfully disagree with your position here.  The risk of
using the same key is that a malicious user could target a particular
queue with a DoS attack, but how is that different than any single
queue device?  NAPI protects a single queue against (a network
interrupt based) DoS.  I do not think we should be generating a random
key at boot time, and because of the way NAPI mitigates load, we are
okay.  The gain from from the far simpler setup (and reproducability)
outweighs the risk until someone can show damage due to this
theoretical DoS attack.
--
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