netdev - Re: [PATCH v2 net-next 0/6] Allow bridge to function in non-promisc mode

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: <20130425103557.1e42ad04@nehalam.linuxnetplumber.net>
Date:	Thu, 25 Apr 2013 10:35:57 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Vlad Yasevich <vyasevic@...hat.com>, netdev@...r.kernel.org,
	bridge@...ts.linux-foundation.org
Subject: Re: [PATCH v2 net-next 0/6] Allow bridge to function in non-promisc
 mode

On Thu, 25 Apr 2013 19:45:27 +0300
"Michael S. Tsirkin" <mst@...hat.com> wrote:

> On Thu, Apr 25, 2013 at 08:56:56AM -0700, Stephen Hemminger wrote:
> > On Fri, 19 Apr 2013 16:52:44 -0400
> > Vlad Yasevich <vyasevic@...hat.com> wrote:
> > 
> > > This series is an almost complete rework of the prior attempt
> > > to make the bridge function in non-promisc mode.  In this series
> > > the "promiscuity" of an interface is dynamically determined and
> > > the interface may transition from/to promiscuous mode based on
> > > bridge configuration.
> > > 
> > > The series keeps an idea of an "uplink" port.  That is still user
> > > designated.
> > > The series also adds a concept of "dynamic" bridge port.  This is
> > > the default state of the port and means that the user has not
> > > specified any static FDBs for that port.
> > > Once a user has added a static FDB entry to port and also specified
> > > an "uplink" flag for that FDB, the mac address from that FDB is
> > > added to the bridge hw address list and synched down to uplinks.
> > > "Uplinks" are always considered dynamic ports even if a static entry
> > > has been added for them.
> > > Promiscuity is determined by the number of dynamic ports.  If there
> > > are no dynamic ports (i.e all ports have static FDBs set), then we
> > > know all the neighbors and can switch promisc off on all of the ports.
> > > If we have only 1 dynamic port and its an uplink, we can synch all
> > > static hw addresses to this port and mark it non-promisc.
> > > If we have more then 1 dynamic port, then all ports have to be
> > > promiscuouse.
> > > This is the algorith that Michael Tsirkin proposed earlier.
> > 
> > Instead of a uplink port, maybe this idea would work better in combination
> > with another patch I have been working on.
> > 
> > In many bridged environments, ports have only one possible MAC address
> > on the other side. My patch provides a flag to mark those ports as bound
> > with only one peer MAC address.  This allows those ports to be skipped on
> > flooding, and for security only packets with that source address would
> > be allowed.
> > 
> > After that change, your promicious code could just use that flag:
> > i.e: 
> >    uplink ports = total ports - bound ports
> >    if (uplink ports == 1)
> >        enter non-promicious mode
> 
> Almost except sometimes (with some guests)
> X mac addresses are needed, not just one.
> 
> How about a generalization:
> 	- a flag to disable learning per port (only use static entries)
> 	- a flag to disable flood per port
> Both sees to exist on openbsd, they are useful by themselves.
> 
> Now Vlad's patch can work if both learning and flood are
> disabled for all ports except maybe one.
> 
> 

Ok, then maybe allow multiple bound MAC address's per guest.
And more flags seems like a good and easy solution to per-port
control. If you have tested code, please submit it.
--
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