netdev - Re: [PATCH v9 net-next 00/12] Add basic VLAN support to bridges

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: <51142F20.4050008@redhat.com>
Date:	Thu, 07 Feb 2013 17:48:00 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	unlisted-recipients:; (no To-header on input)
CC:	Stephen Hemminger <stephen@...workplumber.org>,
	bridge@...ts.linux-foundation.org, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH v9 net-next 00/12] Add basic VLAN support to bridges

On 02/04/2013 11:58 AM, Vlad Yasevich wrote:
> On 02/04/2013 11:24 AM, Stephen Hemminger wrote:
>> One thing I am not clear about is whether is supposed to be just
>> a simple filter of VLAN traffic, or a full VLAN aware bridge.
>
> I started with the concept of basic VLAN filtering, but it has been
> morphing into more of a VLAN away bridge.
>
>>
>> The change to make FDB entries per-VLAN seems to be the biggest tipping
>> point into a full VLAN bridge. I am concerned that might break existing
>> API's and Spanning Tree (internal and external).
>>
>
> I debated for a while about whether per-VLAN FDB entries were needed.
> The typing point was that without it, you may end up with flopping FDB
> and possible packet drops or vlan leaks, if say 2 different VMs used the
> same MAC but different VLANs.  Without it, there is an exploitable gap.
>
> I've also tried to separate FDB code changes as much as possible.  If
> you really thing this is a big risk and a barrier to entry, then we can
> drop them.  I am just concerned about the hole I described above, but I
> guess it is not much different then what's there now.
>

So I played with STP for quite a bit and found the FDB changes have 
absolutely no effect on operation of STP.
Since all the vlan filtering code is mostly in forwarding path, STP 
works just fine.
Looking at STP code (the one in the kernel), I don't see any 
dependencies on FDB.  The only userspace code I can find is from here
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git.  That 
only seems to ask for RTM_GETLINK, and there you will not get any vlan 
information if you don't set the filter flags.

So, I don't see any API impact as far as STP is concerned.

-vlad


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