netdev - Re: llc needs namespace awareness asap, was Re: Patch fixing STP if bridge in non-default namespace.

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: Tue, 11 Jul 2023 22:06:45 -0500
From: Harry Coin <hcoin@...etfountain.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, netdev@...r.kernel.org
Subject: Re: llc needs namespace awareness asap, was Re: Patch fixing STP if
 bridge in non-default namespace.

On 7/11/23 19:55, Andrew Lunn wrote:
>> Something like that, but to your point about regression -- It a
>> statistically good bet there are many bridges with STP enabled in
>> non-default name spaces that simply have no loops in L2 BUT these are
>> 'buried'  inside docker images or prepackaged setups that work 'just fine
>> standalone' and also 'in lab namespaces (that just don't have L2 loops...)
>> and so that don't hit the bug.  These users are one "cable click to an open
>> port already connected somewhere they can't see" away from bringing down
>> every computer on their entire link (like me, been there, it's not a happy
>> week for anyone...), they just don't know it.  And their vendors 'trust STP,
>> so that can't be it' --- but it is.
>>
>> If the patch above gets installed-- then packagers downstream will have to
>> respond with effort to add code to turn off STP if finding themselves in a
>> namespace, and not if not.   They will be displeased at having to
>> accommodate then de-accommodate when the fix lands.   As a 'usually
>> downstream of the kernel' developer, I'd rather be warned than blocked.
> I don't know this code at all, so maybe a dumb question. What about
> user space STP and RSTP? Do they get to see BPDUs? If that works, we
> need to ensure any checking you add does not break that use case.
>
> 	Andrew

Andrew, the only RTSP / STP provider I know of is open-vswitch and their 
docs (last I read them) provide the caution to use veth pairs to 
namespaces, but not run their daemon there--- and fair enough as no 
multicast llc would make it to that code in a namespace as currently 
kernel implemented.

Like STP and namespaces in bridge code quite happily accepting commands 
it fails to deliver (though it's properly a subject for another related 
thread, you really have to read lots of fine print to notice the kernel 
bridge code has both STP and vlan capability, but they do *not* play 
well robustly though the system happily accepts configs like they do 
(STP BPDUs appropriate to one vlan can go out untagged..)

Anyhow, to your point:  As zero multicast L2 packets make it to the 
kernel protocols stacks, much less user space if they aren't in the 
default net name space, this fix at most would allow packets they 
presently expect, are documented to get, but somehow magically never 
arrive -- to arrive.

Put more 'mathematically':  Neither the bug nor its fix will change 
anything in the primary namespace, neither the bug nor its fix will 
change packets that presently arrive in the non-default namespace to 
behave other than as now they do.  The only change should be to cause 
multicast packets that ought to be delivered to listeners in the 
non-default namespace to get them.

HTH

Harry Coin

Bettendorf, Iowa

--