netdev - Re: [patch net-next-2.6] net: reinject arps into bonding slave instead of master

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]

Message-ID: <20110309133338.GA18232@hmsreliant.think-freely.org>
Date:	Wed, 9 Mar 2011 08:33:39 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
Cc:	Andy Gospodarek <andy@...yhouse.net>,
	Jiri Pirko <jpirko@...hat.com>, netdev@...r.kernel.org,
	davem@...emloft.net, shemminger@...ux-foundation.org,
	kaber@...sh.net, fubar@...ibm.com, eric.dumazet@...il.com
Subject: Re: [patch net-next-2.6] net: reinject arps into bonding slave
	instead of master

On Tue, Mar 08, 2011 at 10:44:37PM +0100, Nicolas de Pesloüan wrote:
> Le 08/03/2011 14:42, Andy Gospodarek a écrit :
> >I'm pretty sure this patch will have the same catastrophic problem your
> >last one did.  By cloning and setting skb2->dev = orig_dev you just
> >inserted a frame identical to the one we received right back into the
> >stack.  It only took a few minutes for my box to melt as one frame on
> >the wire will cause an infinite number of frames to be received by the
> >stack.
> 
> I agree with Andy. We still keep one reinject (netif_rx), which is
> probably better that two (__netif_receive_skb), but not enough.
> 
> I really think we need a general framework for late delivery of
> final packets to packet handler registered somewhere in the
> rx_handler path.
> 
> Jiri, is this patch the one you announced as "I have some kind nice
> solution in mind and I'm going to submit that as a patch later (too
> many patches are in the wind atm)" ?


I've not had time to flesh any of this out, but have you considered the use of
privately allocated net namespaces to define the receive order of frames when
doing multiple re-injections through netif_rx/netif_receive_skb.  If you
modified the ptype list traversals so validate that dev_net(ptype->dev) ==
dev_net(skb->dev) before delivery, you could allocate private net namespaces in
your virutal master drivers (bridges/bonds/vlans) and place the slave devices in
those spaces, so that only the parent device could receive frames on them.

Of course thats going to have its own set of problems to deal with, but it might
be worth considering.
Neil

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