linux-kernel - Re: [RFC net-next (resend) 2/4] net: bridge: send notification for roaming hosts

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: <e562704277f5d64a37ea67789b8e7d13d2cb12a4.camel@alliedtelesis.co.nz>
Date: Sun, 24 Nov 2024 21:23:17 +0000
From: Elliot Ayrey <Elliot.Ayrey@...iedtelesis.co.nz>
To: "andrew@...n.ch" <andrew@...n.ch>, "olteanv@...il.com"
	<olteanv@...il.com>, "davem@...emloft.net" <davem@...emloft.net>,
	"razor@...ckwall.org" <razor@...ckwall.org>, "pabeni@...hat.com"
	<pabeni@...hat.com>, "roopa@...dia.com" <roopa@...dia.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "f.fainelli@...il.com"
	<f.fainelli@...il.com>, "horms@...nel.org" <horms@...nel.org>,
	"kuba@...nel.org" <kuba@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"bridge@...ts.linux.dev" <bridge@...ts.linux.dev>
Subject: Re: [RFC net-next (resend) 2/4] net: bridge: send notification for
 roaming hosts

On Sat, 2024-11-09 at 15:40 +0200, Nikolay Aleksandrov wrote:
> No way, this is ridiculous. Changing the port like that for a notification is not
> ok at all. It is also not the bridge's job to notify user-space for sticky fdbs
> that are trying to roam, you already have some user-space app and you can catch
> such fdbs by other means (sniffing, ebpf hooks, netfilter matching etc). Such
> change can also lead to DDoS attacks with many notifications.

Unfortunately in this case the only indication we get from the hardware of this
event happening is a switchdev notification to the bridge. All traffic is dropped
in hardware when the port is in this mode so the methods you suggest will not work.

I have changed my implementation to use Andrew's suggestion of using a new attribute
rather than messing with the port. But would this also be more appropriate if the
notification was only triggered when receiving the event from hardware? If not
then do you have any suggestions for getting these kinds of events from hardware
to userspace without going through the bridge?