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]

Message-ID: <CAJ3xEMgY_w-7ACmyHBKwf_p5MhiNPaD+pfidBUQy0+Y8m7TRhA@mail.gmail.com>
Date:	Tue, 24 Feb 2015 11:19:58 +0200
From:	Or Gerlitz <gerlitz.or@...il.com>
To:	"Rose, Gregory V" <gregory.v.rose@...el.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

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
>> 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.

Oops, sorry, these two terms were borrowed from the ESX jargon, and I
was under the maybe misconception they are part of the Linux speak
too, anyway

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

yes, this == VST (Virtual Switch Tagging), which is more common I
believe, called "access mode" in physical switches

vs. the more standard model where the driver is allowed to
insert/remove VLAN tags under its own control (still with HW assist).

yes, this is VGT (Virtual Guest Tagging), called "trunk mode" in
physical switches


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

we were aligned but used different terms.

>  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.

OK, good.


>> >> 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.

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?!

Or.


>
> - Greg
--
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