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

On Fri, 2024-11-08 at 14:42 +0100, Andrew Lunn wrote:
> This sounds a bit hacky. Could you add a new optional attribute to the
> netlink message indicating the roam destination, so there is no need
> to play games with the actual port?

Yes that's another option.

> I'm not too deep into how these all works, but i also wounder about
> backwards compatibility. Old code which does not look for
> FDB_NOTIFY_ROAMING_BIT is going to think it really has moved, with
> your code. By using a new attribute, and not changing the port, old
> code just sees a notification it is on the port it always was on,
> which is less likely to cause issues?

Thanks that's a good point. I'll have a look at making it an attribute
instead.

> And do we want to differentiate between it wants to roam, but the
> sticky bit has stopped that, and it really has roamed?

That is partly what this patch is trying to do, since actually roaming
hosts will already trigger a notification with the new port.

I will try your suggestion as it seems better than what I have here. I
also think moving away from relying on the sticky bit might be good.
This behaviour relies on the port being locked in hardware so it might
be more appropriate for this to be part of locked behaviour in the
kernel also?