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:   Mon, 1 Mar 2021 19:02:51 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Markus Blöchl <Markus.Bloechl@...tronik.com>
Cc:     Michael Walle <michael@...le.cc>, Jakub Kicinski <kuba@...nel.org>,
        "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, 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.