netdev - Re: [RFC PATCH v2 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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Mar 2013 16:23:53 -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 v2 net-next 0/3] Allow bridge to function in non-promisc
 mode

On 03/08/2013 10:17 AM, Vlad Yasevich wrote:
> On 03/08/2013 12:43 AM, Stephen Hemminger wrote:
>> On Thu,  7 Mar 2013 16:28:45 -0500
>> Vlad Yasevich <vyasevic@...hat.com> wrote:
>>
>>> The series adds an ability to configure the bridge into a
>>> non-primiscuous
>>> mode.   Instead, it provides the ability to identitfy some set of bridge
>>> ports as uplinks and allows for MAC addresses to be programmed onto
>>> those ports.  In case the port hardware does not support mac filter,
>>> that port will be placed in promiscuous mode.
>>>
>>> Default bridge operation continues to remain as "promiscuous".  The new
>>> functionality has to be enabled via sysfs (similar to other bridge
>>> extensions).
>>>
>>> The uplink mode is implemented as a flag on a bridge port.  The api to
>>> change that flag follows the existing api to enable/disable other
>>> existing
>>> flags.
>>>
>>> All comments are welcome.
>>>
>>
>> Can we make this a one step process and less visible to the user.
>> If user defines an uplink device, and the uplink device is capable of
>> filtering
>> (and what ever other pre-conditions people can think of), then the
>> bridge will
>> transparently switch to uplink/non-promisc mode.  This can also be
>> used to trigger
>> edge only mode in RSTP in the future.
>>
>> Less knobs.
>>
>
> Ok.  Let me see what I can do.

So I started working through this and realized that this complicates the 
code significantly.

* I have to re-introduce the uplink-list since now I need to track
"filter capable" uplinks in addition to non-capable ones.
* The really nice and simple sysfs interface to set a flag turns into 
something that duplicates code.
* The bridge port removal can effect the promiscuity setting of the 
bridge if the last uplink is removed.
* We lose the ability to run a promisc edge bridge with uplinks.

I am really starting wonder if this is any better?  The changes
are much bigger and more complex while the functional flexibility is
reduced.  Is it really worth removing a configuration knob?

I've attached an in-progress patch to demonstrate the above.

-vlad

-vlad
>
> Thanks
> -vlad
>

View attachment "test.patch" of type "text/x-patch" (8159 bytes)