diff mbox

[dpdk-dev,10/17] net/fm10k/base: improve VF's multi-bit VLAN update requests

Message ID 20170303031727.461-11-qi.z.zhang@intel.com (mailing list archive)
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers show

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Zhang, Qi Z March 3, 2017, 3:17 a.m. UTC
The VF uses a multi-bit update request to clear unused VLANs whenever it
resets. However, an accident in a previous refector broke multi-bit
updates for VFs, due to misreading a comment in fm10k_vf.c and
attempting to reduce code duplication. The problem occurs because
a multi-bit request has a non-zero length, and the PF would simply drop
any request with the upper 16 bits set. In addition, a multi-bit vlan
update does not have a concept for "VLAN 0" as the single bit update
does.

A previous revision of this patch resolved the issue by simply removing
the upper 16 bit check and the iov_select_vid checks. However, this would
remove the checks for default VID and for ensuring no other VLANs can be
enabled except pf_vid when it has been set. To resolve that issue, this
revision uses the iov_select_vid when we have a single-bit update, and
denies any multi-bit update when the VLAN was administratively set by
the PF. This should be ok since the PF properly updates VLAN_TABLE when
it assigns the PF vid. This ensures that requests to add or "remove" the
PF vid work as expected, but a rogue VF could not use the multi-bit
update as a loophole to attempt receiving traffic on other VLANs.

Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
---
 drivers/net/fm10k/base/fm10k_pf.c | 30 ++++++++++++++++++++++--------
 1 file changed, 22 insertions(+), 8 deletions(-)

Comments

Ferruh Yigit March 5, 2017, 11:42 a.m. UTC | #1
On 3/3/2017 3:17 AM, Qi Zhang wrote:
> The VF uses a multi-bit update request to clear unused VLANs whenever it
> resets. However, an accident in a previous refector broke multi-bit

s/refector/refactor

> updates for VFs, due to misreading a comment in fm10k_vf.c and
> attempting to reduce code duplication. The problem occurs because
> a multi-bit request has a non-zero length, and the PF would simply drop
> any request with the upper 16 bits set. In addition, a multi-bit vlan
> update does not have a concept for "VLAN 0" as the single bit update
> does.
> 
> A previous revision of this patch resolved the issue by simply removing
> the upper 16 bit check and the iov_select_vid checks. However, this would
> remove the checks for default VID and for ensuring no other VLANs can be
> enabled except pf_vid when it has been set. To resolve that issue, this
> revision uses the iov_select_vid when we have a single-bit update, and
> denies any multi-bit update when the VLAN was administratively set by
> the PF. This should be ok since the PF properly updates VLAN_TABLE when
> it assigns the PF vid. This ensures that requests to add or "remove" the
> PF vid work as expected, but a rogue VF could not use the multi-bit
> update as a loophole to attempt receiving traffic on other VLANs.
> 
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>

<...>
diff mbox

Patch

diff --git a/drivers/net/fm10k/base/fm10k_pf.c b/drivers/net/fm10k/base/fm10k_pf.c
index 878d46e..4c075b6 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -1271,18 +1271,32 @@  s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 **results,
 		if (err)
 			return err;
 
-		/* verify upper 16 bits are zero */
-		if (vid >> 16)
-			return FM10K_ERR_PARAM;
-
 		set = !(vid & FM10K_VLAN_CLEAR);
 		vid &= ~FM10K_VLAN_CLEAR;
 
-		err = fm10k_iov_select_vid(vf_info, (u16)vid);
-		if (err < 0)
-			return err;
+		/* if the length field has been set, this is a multi-bit
+		 * update request. For multi-bit requests, simply disallow
+		 * them when the pf_vid has been set. In this case, the PF
+		 * should have already cleared the VLAN_TABLE, and if we
+		 * allowed them, it could allow a rogue VF to receive traffic
+		 * on a VLAN it was not assigned. In the single-bit case, we
+		 * need to modify requests for VLAN 0 to use the default PF or
+		 * SW vid when assigned.
+		 */
 
-		vid = err;
+		if (vid >> 16) {
+			/* prevent multi-bit requests when PF has
+			 * administratively set the VLAN for this VF
+			 */
+			if (vf_info->pf_vid)
+				return FM10K_ERR_PARAM;
+		} else {
+			err = fm10k_iov_select_vid(vf_info, (u16)vid);
+			if (err < 0)
+				return err;
+
+			vid = err;
+		}
 
 		/* update VSI info for VF in regards to VLAN table */
 		err = hw->mac.ops.update_vlan(hw, vid, vf_info->vsi, set);