netdev - Re: [PATCH v2 net 5/6] net: enetc: don't disable VLAN filtering in IFF

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:   Sat, 27 Feb 2021 02:16:51 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Michael Walle <michael@...le.cc>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Markus Blöchl <Markus.Bloechl@...tronik.com>
Subject: Re: [PATCH v2 net 5/6] net: enetc: don't disable VLAN filtering in
 IFF_PROMISC mode

On Fri, Feb 26, 2021 at 03:49:22PM -0800, Jakub Kicinski wrote:
> On Sat, 27 Feb 2021 01:42:44 +0200 Vladimir Oltean wrote:
> > On Fri, Feb 26, 2021 at 03:28:36PM -0800, Jakub Kicinski wrote:
> > > I don't understand what you're fixing tho.
> > >
> > > Are we trying to establish vlan-filter-on as the expected behavior?
> >
> > What I'm fixing is unexpected behavior, according to the applicable
> > standards I could find. If I don't mark this change as a bug fix but as
> > a simple patch, somebody could claim it's a regression, since promiscuity
> > used to be enough to see packets with unknown VLANs, and now it no
> > longer is...
>
> Can we take it into net-next? What's your feeling on that option?

I see how you can view this patch as pointless, but there is some
context to it. It isn't just for tcpdump/debugging, instead NXP has some
TSN use cases which involve some asymmetric tc-vlan rules, which is how
I arrived at this topic in the first place. I've already established
that tc-vlan only works with ethtool -K eth0 rx-vlan-filter off:
https://lore.kernel.org/netdev/CA+h21hoxwRdhq4y+w8Kwgm74d4cA0xLeiHTrmT-VpSaM7obhkg@mail.gmail.com/
and that's what we recommend doing, but while adding the support for
rx-vlan-filter in enetc I accidentally created another possibility for
this to work on enetc, by turning IFF_PROMISC on. This is not portable,
so if somebody develops a solution based on that in parallel, it will
most certainly break on other non-enetc drivers.
NXP has not released a kernel based on the v5.10 stable yet, so there is
still time to change the behavior, but if this goes in through net-next,
the apparent regression will only be visible when the next LTS comes
around (whatever the number of that might be). Now, I'm going to
backport this to the NXP v5.10 anyway, so that's not an issue, but there
will still be the mild annoyance that the upstream v5.10 will behave
differently in this regard compared to the NXP v5.10, which is again a
point of potential confusion, but that seems to be out of my control.

So if you're still "yeah, don't care", then I guess I'm ok with leaving
things alone on stable kernels.