netdev - Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets

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:	Fri, 20 Mar 2015 14:03:03 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	John Fastabend <john.r.fastabend@...el.com>
CC:	davem@...emloft.net, sfeldma@...il.com, jiri@...nulli.us,
	ronen.arad@...el.com, netdev@...r.kernel.org,
	Wilson Kok <wkok@...ulusnetworks.com>
Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded
 packets

On 3/20/15, 10:11 AM, John Fastabend wrote:
> On 03/20/2015 09:58 AM, roopa@...ulusnetworks.com wrote:
>> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>>
>> On a Linux bridge with bridge forwarding offloaded to switch ASIC,
>> there is a need to not re-forward frames that have already been
>> forwarded in hardware.
>>
>> Typically these are broadcast or multicast frames forwarded by the
>> hardware to multiple destination ports including sending a copy of
>> the packet to the cpu (kernel e.g. an arp broadcast).
>> The bridge driver will try to forward the packet again, resulting in
>> two copies of the same packet.
>>
>> These packets can also come up to the kernel for logging when they hit
>> a LOG acl rule in hardware. In such cases, you do want the packet
>> to go through the bridge netfilter hooks. Hence, this patch adds the
>> required checks just before the packet is being xmited.
>>
>> v2:
>> 	- Add a new hw_fwded flag in skbuff to indicate that the packet
>> 	is already hardware forwarded. Switch driver will set this flag.
>> 	I have been trying to avoid having this flag in the skb
>> 	and thats why this patch has been in my tree for long. Cant think
>> 	of other better alternatives. Suggestions are welcome. I have put
>> 	this under CONFIG_NET_SWITCHDEV to minimize the impact.
>>
>> Signed-off-by: Roopa Prabhu <roopa@...ulusnetworks.com>
>> Signed-off-by: Wilson Kok <wkok@...ulusnetworks.com>
>> ---
> Interesting. I completely avoid this problem by not instantiating a
> software bridge ;)
>   When these pkts come up the stack I either use a
> raw socket to capture them, put a 'tc' ingress rule to do something,
> or have OVS handle them in some special way.
> It seems to me that this
> is where the sw/hw model starts to break when you have these magic
> bits to handle the packets differently.

  In-kernel bridge driver is proven very useful for us to run stp,
or recently igmp reports (dont know the details here) etc in software.
I wonder how you handle these. If you don't use the in-kernel bridge
driver, I suspect you down the lane you will end-up having to duplicate a
lot of things that bridge driver already does in your switch driver.
>
> How do you know to set the skb bit? Do you have some indicator in the
> descriptor? I don't have any good way to learn this on my hardware. But
> I can assume if it reached the CPU it was because of some explicit rule.

Right now we tag all packets except for some igmp frames so that they 
get handled by software (in kernel bridge driver).
(But the igmp frames check is a bit of a hack right now). We don't use 
it today, but, the sdk
can give us some details about the reason the packet was sent to CPU (It 
possibly gets it from the descriptor).


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html