netdev - Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

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: <20120306140957.GA27559@wantstofly.org>
Date:	Tue, 6 Mar 2012 15:09:57 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	jhs@...atatu.com
Cc:	John Fastabend <john.r.fastabend@...el.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	bhutchings@...arflare.com, roprabhu@...co.com,
	netdev@...r.kernel.org, mst@...hat.com, chrisw@...hat.com,
	davem@...emloft.net, gregory.v.rose@...el.com, kvm@...r.kernel.org,
	sri@...ibm.com, Chris Healy <chealy@...co-us.com>
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

On Tue, Mar 06, 2012 at 08:42:26AM -0500, jamal wrote:

> > net/dsa currently configures any switch chips in the system to do
> > auto-learning.  
> 
> So we clearly need the (user configurable) knob to turn on/off learning.

Why so?  (I think the switch chips should just never do learning at
all..)

> I think it should also be upto the admin to decide whether the learning
> happens in the kernel or user space.

I can't see any point in doing it in userspace.  What would be the
advantage of that?  And based on what would the admin make the decision?

> > However, I would much prefer to disable that, and have
> > the switch chip just pass up packets for new source addresses, have
> > Linux do the learning, and then mirror the Linux software FDB into
> > the hardware instead -- that avoids having to manually flush the
> > hardware FDB on certain STP state transitions or having to configure
> > the hardware to use a shorter address learning timeout when we're in
> > the middle of an STP topology change, which are problems we are
> > running into in practice.
> 
> So in the scenario you are describing then it seems the h/ware has
> no stp state toggles, correct?  In other ASICs i have seen, there is
> influence from stp state on behavior.

It does, there is an STP state field per port in the switch chip,
which controls whether learning takes place on this port (in
Learning and Forwarding states) and whether packets are forwarded
(in the Forwarding state).

But e.g. it doesn't automatically flush this port's FDB entries if
you move a port from Forwarding to Listening -- the STP state field
only controls direct learning and forwarding for received packets.

And when you receive a BPDU with the topology change notification
bit set, the switch won't automatically shorten the FDB entry
timeout for you until the topology change is over, either.

> > Just curious -- while your patches allow propagating FDB entries
> > into the hardware, do you also have hooks to tell the hardware which
> > ports are to share address databases?
> 
> I think those are missing in this discussion and makes a lot of
> sense to be part of the interface.

Keep in mind that these chips also do VLAN tagging in hardware, and
so a scenario like:

	# brctl addbr br123
	# brctl addif br123 lan1.123
	# brctl addif br123 lan2.123

is also one that can be handled in hardware (which the current
patchwork patch doesn't handle yet).

> > net/dsa currently solves this by not having the hardware handle
> > broadcast packets at all, which circumvents the problem, but for
> > multicast traffic you would still like to be able to do at least the
> > forwarding that can be done in hardware in hardware.  (Unicast doesn't
> > have this problem as long as the kernel and the switch chip agree on
> > their view of the FDB.)
> 
> Of course this could represent an interesting opportunity for a DOS.
> Even at 4 port switch at 100Mbs, hitting 500Kpps to the CPU (I am
> thinking these tiny switches end up in some tiny MIPS/ARM cpu) could
> be devastating. How do you deal with that?

You can let the switch rate limit the number of packets passed up to
the CPU.  500 kp/s broadcast traffic seems somewhat excessive in any
case, and I'm not sure if this deserves handling apart from QoSing
those streams to manageable levels.

thanks,
Lennert
--
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