netdev - RE: be2net: SR-IOV, vlan isolation issue

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] [day] [month] [year] [list]

Date:	Wed, 14 Jan 2015 06:26:00 +0000
From:	Sathya Perla <Sathya.Perla@...lex.Com>
To:	Yoann Juet <veilletechno-irts@...v-nantes.fr>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Yoann Juet <yoann.juet@...v-nantes.fr>
Subject: RE: be2net: SR-IOV, vlan isolation issue

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> 
> Hi all,
> 
> I recently discovered unattended behavior from Emulex cards with KVM
> hypervisor and SR-IOV. On such 10Gbps cards (be2net module, Emulex
> OneConnect OCm14102-U3-D devices), guest machines attached to VFs on
> the
> Emulex Physical Functions (PF) see all multicast and broadcast (not
> unicast) traffic from/to other VM located on the same PF **BUT** on
> other vlans. Just put into promiscuous mode the guest machine's
> interface and you will observe inbound, outbound (multicast + broadcast
> only) irrelevant traffic.
> 
> Please note that irrelevant traffic is not sent to the guest machine
> TCP/IP stack. No firewall hitting for instance. The issue is about
> traffic monitoring with a VF put into promiscuous mode using a sniffer
> like tshark, tcpdump... Vlan isolation seems not 100% effective from the
> guest perspective since mcast+bcast information leaks.
> 
> A similar issue has already been observed with Broadcom cards and then
> patched by the developer team. Refer to the post in archive "bnx2x +
> SR-IOV, no internal L2 switching", 12 Feb 2014. Emulex driver seems to
> suffer the same problem, isn't it ?
> 

Yoann, thanks for reporting this issue. This issue is caused because
the VF was allowed to go into vlan-promiscuous mode by the PF.
We'll try to provide a fix for this soon...

thanks,
-Sathya