netdev - Re: [PATCH/RFC net-next] rocker: forward packets to CPU when a port in promiscuous mode

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, 08 Jul 2015 22:38:51 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Simon Horman <simon.horman@...ronome.com>,
	Scott Feldman <sfeldma@...il.com>,
	Jiri Pirko <jiri@...nulli.us>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH/RFC net-next] rocker: forward packets to CPU when a port
 in promiscuous mode

On 15-07-08 09:25 PM, Simon Horman wrote:
> This change allows the CPU to see all packets seen by a port when the
> netdev associated with the port is in promiscuous mode.
> 
> This change was previously posted as part of a larger patch and in turn
> patchset which also aimed to allow rocker interfaces to receive packets
> when not bridged. That problem has subsequently been addressed in a
> different way by Scott Feldman.
> 
> When this change was previously posted Scott indicated that he had some
> reservations about sending all packets from a switch to the CPU. The
> purpose of posting this patch is to start discussion of weather this
> approach is appropriate and if not how else we might move forwards.
> 
> In my opinion if host doesn't want all packets its shouldn't put a port
> in promiscuous mode. But perhaps that is an overly naïve view to take.
> 
> My main motivation for this change at this time is to allow rocker to
> work with Open vSwitch and it appears that this change is sufficient to
> reach that goal. Another approach might be to teach
> rocker_port_master_changed() about Open vSwitch.
> 

My opinion would be to not confuse a host concept 'promiscuous mode'
and allow it to impact how the forwarding is done by the hardware. I
think a better approach would be to put a default low priority rule in
one of the hardware match action tables to mirror all traffic to the
port you want to mirror traffic to. And if it happens to be a CPU port
then it will be pushed to the host.

My problem with the semantics here is it seems overload how we use
promiscuous mode in the NIC today. For example I don't see how to use
it in an SR-IOV case or multi-function device. How would you handle
this if more than one port was put in promiscuous mode? Mirror to both
ports? Today when we put a device in a promiscuous mode behind a
switch we don't expect to start receiving all traffic.

I think at very least we need to be very specific about how we define
it and when it applies if we overload promisc field. Also wouldn't
it break any 'bridge/vswitch' software that puts the port in promisc
mode by default.

> In the longer term I believe Open vSwitch should be able to program
> flows into rocker 'hardware' and thus not all packets would reach the CPU.

Agree with this point.

> 
> Signed-off-by: Simon Horman <simon.horman@...ronome.com>
> ---
>  drivers/net/ethernet/rocker/rocker.c | 33 +++++++++++++++++++++++++++++----
>  1 file changed, 29 insertions(+), 4 deletions(-)
> 

--
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