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] [day] [month] [year] [list]

Message-ID: <20210301121752.0b836afa@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 1 Mar 2021 12:17:52 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Markus Blöchl <Markus.Bloechl@...tronik.com>,
        Michael Walle <michael@...le.cc>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH v2 net 5/6] net: enetc: don't disable VLAN filtering in
 IFF_PROMISC mode

On Mon, 1 Mar 2021 19:02:51 +0200 Vladimir Oltean wrote:
> On Mon, Mar 01, 2021 at 05:26:53PM +0100, Markus Blöchl wrote:
> > The main problem here could also just be that almost everybody _thinks_
> > that promiscuity means receiving all frames and no one is aware of the
> > standards definition.
> > In fact, I can't blame them, as the standard is hard to come by and not
> > enjoyable to read, imho. And all secondary documentation I could find
> > on the internet explain promiscuous mode as a "mode of operation" in which
> > "the card accepts every Ethernet packet sent on the network" or similar.
> > Even libpcap, which I consider the reference on network sniffing, thinks
> > that "Promiscuous mode [...] sniffs all traffic on the wire."
> > 
> > Thus I still think that this issue is also fixable by proper
> > documentation of promiscuity.
> > At least the meaning and guarantees of IFF_PROMISC in this kernel should
> > be clearly defined - in one way or the other - such that users with
> > different expectations can be directed there and drivers with different
> > behavior can be fixed with that definition as justification.  
> 
> If Jakub and/or David give us the ACK, I will go ahead and update the
> documentation (probably Documentation/networking/netdevices.rst) to
> mention what does IFF_PROMISC cover, _separate_ from this series.

How do we do this in practical terms?

It'd definitely be very useful to write up the discussions but we 
can't expect that all existing drivers get converted, and incorrect
documentation is worse than none at all.

IIRC Ido also pointed out that the bridge driver follows the "promisc
includes VLAN", so SW drivers would need to be updated as well.

I personally agree with the interpretation that PROMISC == disable DA
filter, but we can't reasonably expect all drivers to follow it.
All I can think of is documenting that the driver _may_ not disable
VLAN filter, and that's our recommendation for new drivers, therefore
users who want "vlan promisc" _must_ disable rx-vlan but the inverse is
not guaranteed (rx-vlan on + PROMISC == only frames for known VLANs).

What's your thinking?