netdev - Re: [RFC PATCH 4/4] net: dsa: tag_edsa: support reception of packets from lag devices

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:   Wed, 28 Oct 2020 16:28:23 +0100
From:   "Tobias Waldekranz" <tobias@...dekranz.com>
To:     "Vladimir Oltean" <olteanv@...il.com>
Cc:     <andrew@...n.ch>, <vivien.didelot@...il.com>,
        <f.fainelli@...il.com>, <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 4/4] net: dsa: tag_edsa: support reception of
 packets from lag devices

On Wed Oct 28, 2020 at 3:05 PM CET, Vladimir Oltean wrote:
> On one hand, I feel pretty yucky about this change.
> On the other hand, I wonder if it might be useful under some conditions
> for drivers with DSA_TAG_PROTO_NONE? For example, once the user bridges
> all slave interfaces, then that bridge will start being able to send and
> receive traffic, despite none of the individual switch ports being able
> to do that. Then, you could even go off and bridge a "foreign"
> interface,
> and that would again work properly. That use case is not supported
> today,
> but is very useful.
>
> Thoughts?

In a scenario like the one you describe, are you saying that you would
set skb->dev to the bridge's netdev in the rcv op?

On ingress I think that would work. On egress I guess you would be
getting duplicates for all multi-destination packets as there is no
way for the none-tagger to limit it, right? (Unless you have the
awesome tx-offloading we talked about yesterday of course :))

I think bridging to "foreign" interfaces still won't work, because on
ingress the packet would never be caught by the bridge's rx
handler. In order for something to be received by br_input.c, it has
to pass through an interface that is attached to it, no?  Everything
above the bridge (like VLAN interfaces) should still work though.