netdev - RE: [net-next 02/10] ixgbevf: Fix broken trunk vlan

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: <43F901BD926A4E43B106BF17856F0755019C5E5E44@orsmsx508.amr.corp.intel.com>
Date:	Tue, 27 Sep 2011 09:39:15 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Jesse Gross <jesse@...ira.com>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	Jiri Pirko <jpirko@...hat.com>
Subject: RE: [net-next 02/10] ixgbevf: Fix broken trunk vlan

> -----Original Message-----
> From: Jesse Gross [mailto:jesse@...ira.com]
> Sent: Monday, September 26, 2011 5:54 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; davem@...emloft.net; netdev@...r.kernel.org;
> gospo@...hat.com; Jiri Pirko
> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
> 
> 
> OK, maybe due to hardware limitations what I'm looking for just really
> isn't possible.

From what I can tell that is the case.

>  However, what I'm trying to emphasize is that vconfig
> is not the only way that vlans can be consumed by the network stack
> and active_vlans is just an indication of whether a vlan filter was
> set, nothing more (perhaps I should have picked a better name when I
> originally designed this stuff).

Understood.  The VF is incapable of receiving VLAN traffic unless a filter has been set.  It doesn't do promiscuous mode and any path that doesn't actually end up setting a VLAN filter won't receive any VLAN traffic.

>  In particular, it is not intended to
> determine whether a tag should be stripped off or not because
> non-vconfig users don't necessarily know which vlans they care about
> (think tcpdump or trunking over a bridge).  A major goal of the
> existing vlan infrastructure is to avoid having drivers make
> assumptions about the consumer of the tag and instead just hand all
> information over to the network stack so it can behave in a consistent
> manner.  That's why I was looking for alternate ways to get this
> information without depending on active_vlans as this driver behaves
> quite a bit differently from others, include the ixgbe PF driver.

There are only two paths for the ixgbevf driver to receive VLAN traffic.  Either a VLAN filter has been set, which will result in a bit tag in active_vlans being set or the system administrator in the host VMM has put the VF device in trunk VLAN mode using the 'ip link set <dev> vf <n> <vlanid>' path.  There is no other way for it to receive VLAN traffic, so I think we're fine.  And keep in mind, once the system admin has put the VF device in trunk vlan mode, the VF is no longer allowed, as a policy implemented in the PF driver, to set any other VLAN filters.  Even if it did, it wouldn't work due to the operational characteristics of the VF device HW.

The methods by which the ixgbe driver, as a fully featured Physical Function device, are quite a bit more varied.  I believe you're thinking of the VF device as a typical Ethernet device and that is just not the case.

- Greg