Re: [PATCH net-next v1 1/1] net: bridge: ensure that link-local traffic cannot unlock a locked port

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Jul 04, 2022 at 04:36:12PM +0200, Hans S wrote:
> On Mon, Jul 4, 2022 at 1:00 PM Ido Schimmel <idosch@nvidia.com> wrote:
> >
> > On Mon, Jul 04, 2022 at 09:54:31AM +0200, Hans S wrote:
> > > >
> > > > IIUC, with mv88e6xxx, when the port is locked and learning is disabled:
> > > >
> > > > 1. You do not get miss violation interrupts. Meaning, you can't report
> > > > 'locked' entries to the bridge driver.
> > > >
> > > > 2. You do not get aged-out interrupts. Meaning, you can't tell the
> > > > bridge driver to remove aged-out entries.
> > > >
> > > > My point is that this should happen regardless if learning is enabled on
> > > > the bridge driver or not. Just make sure it is always enabled in
> > > > mv88e6xxx when the port is locked. Learning in the bridge driver itself
> > > > can be off, thereby eliminating the need to disable learning from
> > > > link-local packets.
> > >
> > > So you suggest that we enable learning in the driver when locking the
> > > port and document that learning should be turned off from user space
> > > before locking the port?
> >
> > Yes. Ideally, the bridge driver would reject configurations where
> > learning is enabled and the port is locked, but it might be too late for
> > that. It would be good to add a note in the man page that learning
> > should be disabled when the port is locked to avoid "unlocking" the port
> > by accident.
> 
> Well you cannot unlock the port by either enabling or disabling
> learning after the port is locked, but Mac-Auth and refreshing might
> not work. I clarify just so that no-one gets confused.

I was referring to the fact that if learning is enabled, a host can
populate the FDB with whatever MAC it wants by crafting a link-local
packet with this MAC as SA. Subsequent packets with this MAC as SA will
pass the locking check in the bridge driver.

> I can do so that the driver returns -EINVAL if learning is on when
> locking the port, but that would of course only be for mv88e6xxx...

Working around this issue in the mv88e6xxx driver is the correct thing
to do, IMO. We avoid leaking this implementation detail (i.e., forcing
learning to be enabled) to user space, which in turn helps us avoid
working around issues created by it (this patch, for example).