netdev - Re: [RFC PATCH net-next 0/3] 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] [day] [month] [year] [list]

Message-ID: <5138D08C.8010307@redhat.com>
Date:	Thu, 07 Mar 2013 12:38:20 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
CC:	netdev@...r.kernel.org, bridge@...ts.linux-foundation.org
Subject: Re: [RFC PATCH net-next 0/3] Allow bridge to function in non-promisc
 mode

On 03/07/2013 12:13 PM, Stephen Hemminger wrote:
> On Thu, 07 Mar 2013 10:35:37 -0500
> Vlad Yasevich <vyasevic@...hat.com> wrote:
>
>> On 03/07/2013 02:19 AM, Stephen Hemminger wrote:
>>> I understand the desire to add more functionality, but in this case it
>>> would introduce lots more problems. STP would break and it doesn't seem to
>>> gain anything that can't be done by other means.
>>>
>>> Turning bridge into macvlan seems unnecessary. Combining apples and bananas
>>> doesn't always make a tasty smoothy, sometimes it is just a mess.
>>>
>>> Maybe adding a little more to macvlan to do what you want would be simpler.
>>>
>>
>>
>> It's not really a macvlan over the bridge.  I would agree that
>> particular setup would be a bit odd.  This work enables VMs to manage
>> their mac addresses and to reduce the load on the host by keeping the
>> bridge in promisc mode.
>>
>> Sadly, most kvm network configs still use bridging and have not
>> transitioned to OVS.  macvlan has some limitations as well and I working
>> to address those, but there is a desire for non-promisc bridge.  In
>> this case VMs can manage their mac addresses and can write that data to
>> the bridge.
>>
>> STP is not broken as STP uses multicast mac and we set IFF_ALLMULTI thus
>> continuing to receive and process STP BPDUs.
>>
>> The one thing that would appear to suffer from this is VLAN reception,
>> but the bridge does allow vlan config now and that would have to be
>> configured if VMs wish to use vlans.
>>
>> I am not changing default operation of the bridge.  Default is still
>> promisc.  In fact, one can switch back and forth without any network
>> outages.  This simply adds another mode the the bridge operation.
>>
>
> 1. I am not a fan of the added complexity.
> 2, Don't use sysfs for new API's use netlink instead.

Oh, I had a question for you about this.  I am changing the uplink code 
slightly to pattern more after some of the security features you added 
(like root_block and bpdu_guard).  I makes things simpler.  I would 
really like to provide the sysfs interface, because I checked iproute 
code and I don't see any netlink implementation of those things.

Would that be more agreeable to you?

Thanks
-vlad

I
> 3. It depends on the uplink port providing UNICAST filtering which some
>     physical devices don't do.
>

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