netdev - Re: [RFC PATCH v2 net-next 0/7] Non-promisc bidge ports 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]

Message-ID: <20140430173737.GA24794@redhat.com>
Date:	Wed, 30 Apr 2014 20:37:37 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	Vlad Yasevich <vyasevic@...hat.com>, netdev@...r.kernel.org,
	bridge@...ts.linux-foundation.org, shemminger@...tta.com,
	jhs@...atatu.com, john.r.fastabend@...el.com
Subject: Re: [RFC PATCH v2 net-next 0/7] Non-promisc bidge ports support

On Wed, Apr 30, 2014 at 10:22:41AM -0700, Stephen Hemminger wrote:
> On Tue, 29 Apr 2014 17:20:21 -0400
> Vlad Yasevich <vyasevic@...hat.com> wrote:
> 
> > This patch series is a re-implementation of prior attempts to support
> > non-promiscuous bridge ports.
> > 
> > The basic concept is the same as before.  The bridge keeps
> > track of the ports that support learning and flooding packets
> > to unknown destinations.  We call these ports auto-discovery
> > ports since they automatically discover who is behind them through
> > learning and flooding.  
> > 
> > If flooding and learning are disabled via flags, then the port
> > requires static configuration to tell it which mac addresses
> > are behind it.  This is accomplished through adding of fdbs.
> > These fdbs should be static as dynamic fdbs can expire and systems
> > will become unreachable due to lack of flooding.
> > 
> > If the user marks all ports are needing static configuration then
> > we can safely make them non-promiscuous, we will know all the
> > information about them.
> > 
> > If the user leaves only 1 port as automatic, then we can mark
> > that port as not-promiscuous as well.  One could think of
> > this a edge relay similar to what's support by embedded switches
> > in SRIOV devices.  Since we have all the information about the
> > other ports, we can just program the mac addresses into the
> > single automatic port to receive all necessary traffic.
> > 
> > In other cases, we keep all ports promiscuous as before.
> > 
> > There are some other cases when promiscuous mode has to be turned
> > back on.  One is when the bridge itself if placed in promiscuous
> > mode (use sets promisc flag).  The other is if vlan filtering is
> > turned off.  Since this is the default configuration, the default
> > bridge operation is not changed.
> 
> I like this because it does the right thing and is transparent to
> the user. You might also not want to do it if the underlying device
> does not support multiple MAC addresses 
> ie !(dev->priv_flags & IFF_UNICAST_FLT)

The point being, attempt to add an address to a device without IFF_UNICAST_FLT
will put it right back in promisc mode?

Good point.

> 
> You could even go into looking at L2 offload on lower device.
--
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