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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 23 Feb 2015 22:00:00 +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>
Subject: RE: [net-next 13/16] i40e: Fix i40e_ndo_set_vf_spoofchk

> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@...il.com]
> Sent: Monday, February 23, 2015 1:52 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; David Miller; Linux Netdev List;
> nhorman@...hat.com; sassmann@...hat.com; jogreene@...hat.com
> Subject: Re: [net-next 13/16] i40e: Fix i40e_ndo_set_vf_spoofchk
> 
> On Mon, Feb 23, 2015 at 7:31 PM, Rose, Gregory V
> <gregory.v.rose@...el.com> wrote:
> >> From: Or Gerlitz [mailto:gerlitz.or@...il.com]
> 
> >> > The netdev op that allows the operator to turn MAC/VLAN spoof
> >> > checking on and off did not include the flag for VLAN spoof
> >> > checking.  This patch fixes that problem.
> 
> >> If we're on VST mode, the VF isn't aware their traffic is tagged with
> >> vlan-id Y and if they try to send with vlan-id X I assume you are
> >> forcing it to be Y, right?
> 
> > No, it is dropped and a malicious driver event is registered to the PF
> driver.
> 
> Why are you treating the VF as malicious if under VST mode no one told
> them what vlans are allowed for them to use?

I'm not sure what you mean by VST/VGT modes.  To me you're talking about a port VLAN model where the HW inserts/removes the VLAN tag while the VF driver knows nothing about it vs. the more standard model where the driver is allowed to insert/remove VLAN tags under its own control (still with HW assist).

Is that correct?  I think we need to make sure our terms and definitions match.

 or your PF driver
> communicates the vlan mode (VST/VGT) to the VF?

The PF driver does not need to communicate the VLAN mode to the VF.

> 
> >> If we're on VGT mode, what spoof check you can do? we don't have a
> >> model for allowed vlans, did I miss something?
> 
> > This only applies in instances where the administrator has not set a
> VLAN id for the VF via the 'ip' utility.  In that case, our rule is to
> allow the VF driver to set its own VLAN filters if it so wishes.  This is
> a long standing rule for Intel VF drivers.
> 
> makes sense
> 
> > So, with VLAN spoof checking turned on [...]
> 
> what exactly you mean by "VLAN spoof checking turned on" and how the admin
> tells the PF to go into this mode?

#ip link set <pf interface> vf <n> spoofchk <on/off>

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.

- Greg