netdev - RE: [net-next 13/16] i40e: Fix i40e_ndo_set_vf

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <C5551D9AAB213A418B7FD5E4A6F30A0789266074@ORSMSX108.amr.corp.intel.com>
Date:	Tue, 24 Feb 2015 16:00:22 +0000
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Or Gerlitz <gerlitz.or@...il.com>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"nhorman@...hat.com" <nhorman@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"jogreene@...hat.com" <jogreene@...hat.com>,
	"Rony Efraim" <ronye@...lanox.com>
Subject: RE: [net-next 13/16] i40e: Fix i40e_ndo_set_vf_spoofchk

> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@...il.com]
> Sent: Tuesday, February 24, 2015 1:20 AM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; David Miller; Linux Netdev List;
> nhorman@...hat.com; sassmann@...hat.com; jogreene@...hat.com; Rony Efraim
> Subject: Re: [net-next 13/16] i40e: Fix i40e_ndo_set_vf_spoofchk
> 
> On Tue, Feb 24, 2015 at 12:00 AM, Rose, Gregory V
> <gregory.v.rose@...el.com> wrote:
> >> -----Original Message-----
> >> From: Or Gerlitz [mailto:gerlitz.or@...il.com]
> >> Sent: Monday, February 23, 2015 1:52 PM
> >> To: Rose, Gregory V

[snip]

> > With spoof checking off then the VF can send/receive on any VLAN it
> wants.  With spoof checking on the VLAN filter must exist in the HW
> filtering before the VF can send/receive on that VLAN.
> 
> So we agree that the only thing the VF knows is the MAC which was
> provisioned to them by the admin through the PF, so in that respect, I am
> still not clear what is the criteria for your PF driver to decide they are
> spoofing a vlan-id?!

It's a HW specific criteria - we use various methods in our products that support SR-IOV for HW assisted VLAN filtering on the receive side.  So with spoof checking turned on the VF cannot transmit on a given VLAN without an associated VLAN filter having been set on the receive side.  And the VF's cannot set a VLAN filter without assistance from the PF driver so that provides an opportunity for the system administrator to provide "hooks" or other administrative controls on which VLANs the VF can use.  Again - it is not implemented in our general purpose Linux driver but there are customers who have used our HW to implement their own VLAN filtering controls to limit what VLANs the VF can participate in.

Or the administrator can just turn off spoof checking if they "trust" their VF to set permitted VLAN filters.

- Greg