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]
Message-ID: <559E08EB.1000402@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ