netdev - Re: [patch 7/9][NETNS][IPV6] make mld_max

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:	Thu, 03 Jan 2008 12:00:48 +0100
From:	Daniel Lezcano <dlezcano@...ibm.com>
To:	David Stevens <dlstevens@...ibm.com>
CC:	davem@...emloft.net, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org
Subject: Re: [patch 7/9][NETNS][IPV6] make mld_max_msf per namespace

David Stevens wrote:
> Daniel,
>         I'm not sure what benefit you get from making this per-namespace.
> The point of it is really to prevent one (non-root, even) application from
> killing machine performance with source filters (because maintaining them
> is an n^2 algorithm). It's a weak constraint, but the resources it's 
> protecting are
> the processor and MLDv2 packet counts. If any one namespace has a
> large value, all will have a problem still, and  (even without your 
> patch),
> lots of separate source filters can still cause a problem. What it catches
> is one application creating thousands (or millions) of source filters and
> killing the machine and network with MLDv2 reports as a result. Why
> shouldn't that remain global?
> 
>                                                 +-DLS

Good point.

The problem you are pointing is in the case you have a namespace making 
this variable very big. And you are right this is a problem. But, if we 
make the variable global to all the namespaces, we will not able to 
reduce this value for a specific namespace.

I propose the following solution, at the namespace creation the variable 
value is copied from the initial network namespace, the modification of 
this variable is only valid if the value is less than the initial 
network namespace value.

With this solution, we can handle different values for the namespaces 
but these values are driven by the initial network namespace because 
their values are lesser or equal to the one from the initial network 
namespace.

Is it acceptable ?

--
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