[dpdk-dev] [PATCH] ixgbe: workaround for Security issue in SR-IOV mode

[dpdk-dev] [PATCH] ixgbe: workaround for Security issue in SR-IOV mode

[Wenzhuo Lu]

In SR-IOV mode a VF sending LFC or PFC would throttle the
entire port.
The workaround is to add a filter to drop pause frames from
VFs from sending pause frames.

Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
 drivers/net/ixgbe/ixgbe_pf.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index fd1c4ca..b33f4e9 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -55,6 +55,7 @@
 #define IXGBE_MAX_VFTA     (128)
 #define IXGBE_VF_MSG_SIZE_DEFAULT 1
 #define IXGBE_VF_GET_QUEUE_MSG_SIZE 5
+#define IXGBE_ETHERTYPE_FLOW_CTRL 0x8808
 
 static inline uint16_t
 dev_num_vf(struct rte_eth_dev *eth_dev)
@@ -166,6 +167,46 @@ void ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
 	*vfinfo = NULL;
 }
 
+static void
+ixgbe_add_tx_flow_control_drop_filter(struct rte_eth_dev *eth_dev)
+{
+	struct ixgbe_hw *hw =
+		IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+	struct ixgbe_filter_info *filter_info =
+		IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data->dev_private);
+	uint16_t vf_num;
+	int i;
+
+	/* occupy an entity of ether type filter */
+	for (i = 0; i < IXGBE_MAX_ETQF_FILTERS; i++) {
+		if (!(filter_info->ethertype_mask & (1 << i))) {
+			filter_info->ethertype_mask |= 1 << i;
+			filter_info->ethertype_filters[i] =
+				IXGBE_ETHERTYPE_FLOW_CTRL;
+			break;
+		}
+	}
+	if (i == IXGBE_MAX_ETQF_FILTERS) {
+		RTE_LOG(ERR, PMD, "Cannot find an unused ether type filter"
+				" entity for flow control.\n");
+		return;
+	}
+
+	if (hw->mac.ops.set_ethertype_anti_spoofing) {
+		IXGBE_WRITE_REG(hw, IXGBE_ETQF(i),
+				(IXGBE_ETQF_FILTER_EN |
+				IXGBE_ETQF_TX_ANTISPOOF |
+				IXGBE_ETHERTYPE_FLOW_CTRL));
+
+		vf_num = dev_num_vf(eth_dev);
+		for (i = 0; i < vf_num; i++) {
+			hw->mac.ops.set_ethertype_anti_spoofing(hw, true, i);
+		}
+	}
+
+	return;
+}
+
 int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 {
 	uint32_t vtctl, fcrth;
@@ -262,6 +303,8 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 		IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(i), fcrth);
 	}
 
+	ixgbe_add_tx_flow_control_drop_filter(eth_dev);
+
 	return 0;
 }
 
-- 
1.9.3

[dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs

[Wenzhuo Lu]

This patch will drop flow control frames from being transmitted
from VSIs.
With this patch in place a malicious VF cannot send flow control
or PFC packets out on the wire.

V2:
Reword the comments.

Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
 drivers/net/ixgbe/ixgbe_pf.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index fd1c4ca..b33f4e9 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -55,6 +55,7 @@
 #define IXGBE_MAX_VFTA     (128)
 #define IXGBE_VF_MSG_SIZE_DEFAULT 1
 #define IXGBE_VF_GET_QUEUE_MSG_SIZE 5
+#define IXGBE_ETHERTYPE_FLOW_CTRL 0x8808
 
 static inline uint16_t
 dev_num_vf(struct rte_eth_dev *eth_dev)
@@ -166,6 +167,46 @@ void ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
 	*vfinfo = NULL;
 }
 
+static void
+ixgbe_add_tx_flow_control_drop_filter(struct rte_eth_dev *eth_dev)
+{
+	struct ixgbe_hw *hw =
+		IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+	struct ixgbe_filter_info *filter_info =
+		IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data->dev_private);
+	uint16_t vf_num;
+	int i;
+
+	/* occupy an entity of ether type filter */
+	for (i = 0; i < IXGBE_MAX_ETQF_FILTERS; i++) {
+		if (!(filter_info->ethertype_mask & (1 << i))) {
+			filter_info->ethertype_mask |= 1 << i;
+			filter_info->ethertype_filters[i] =
+				IXGBE_ETHERTYPE_FLOW_CTRL;
+			break;
+		}
+	}
+	if (i == IXGBE_MAX_ETQF_FILTERS) {
+		RTE_LOG(ERR, PMD, "Cannot find an unused ether type filter"
+				" entity for flow control.\n");
+		return;
+	}
+
+	if (hw->mac.ops.set_ethertype_anti_spoofing) {
+		IXGBE_WRITE_REG(hw, IXGBE_ETQF(i),
+				(IXGBE_ETQF_FILTER_EN |
+				IXGBE_ETQF_TX_ANTISPOOF |
+				IXGBE_ETHERTYPE_FLOW_CTRL));
+
+		vf_num = dev_num_vf(eth_dev);
+		for (i = 0; i < vf_num; i++) {
+			hw->mac.ops.set_ethertype_anti_spoofing(hw, true, i);
+		}
+	}
+
+	return;
+}
+
 int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 {
 	uint32_t vtctl, fcrth;
@@ -262,6 +303,8 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 		IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(i), fcrth);
 	}
 
+	ixgbe_add_tx_flow_control_drop_filter(eth_dev);
+
 	return 0;
 }
 
-- 
1.9.3

Re: [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

> -----Original Message-----
> From: Lu, Wenzhuo
> Sent: Thursday, October 22, 2015 3:34 PM
> To: dev@dpdk.org
> Cc: Zhang, Helin; Lu, Wenzhuo
> Subject: [PATCH v2] ixgbe: Drop flow control frames from VFs
> 
> This patch will drop flow control frames from being transmitted from VSIs.
> With this patch in place a malicious VF cannot send flow control or PFC packets
> out on the wire.
> 
> V2:
> Reword the comments.
> 
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
>  drivers/net/ixgbe/ixgbe_pf.c | 43
> +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index
> fd1c4ca..b33f4e9 100644
> --- a/drivers/net/ixgbe/ixgbe_pf.c
> +++ b/drivers/net/ixgbe/ixgbe_pf.c
> @@ -55,6 +55,7 @@
>  #define IXGBE_MAX_VFTA     (128)
>  #define IXGBE_VF_MSG_SIZE_DEFAULT 1
>  #define IXGBE_VF_GET_QUEUE_MSG_SIZE 5
> +#define IXGBE_ETHERTYPE_FLOW_CTRL 0x8808
> 
>  static inline uint16_t
>  dev_num_vf(struct rte_eth_dev *eth_dev) @@ -166,6 +167,46 @@ void
> ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
>  	*vfinfo = NULL;
>  }
> 
> +static void
> +ixgbe_add_tx_flow_control_drop_filter(struct rte_eth_dev *eth_dev) {
> +	struct ixgbe_hw *hw =
> +		IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
> +	struct ixgbe_filter_info *filter_info =
> +		IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data->dev_private);
> +	uint16_t vf_num;
> +	int i;
> +
> +	/* occupy an entity of ether type filter */
> +	for (i = 0; i < IXGBE_MAX_ETQF_FILTERS; i++) {
> +		if (!(filter_info->ethertype_mask & (1 << i))) {
> +			filter_info->ethertype_mask |= 1 << i;
> +			filter_info->ethertype_filters[i] =
> +				IXGBE_ETHERTYPE_FLOW_CTRL;
> +			break;
> +		}
> +	}
> +	if (i == IXGBE_MAX_ETQF_FILTERS) {
> +		RTE_LOG(ERR, PMD, "Cannot find an unused ether type filter"
> +				" entity for flow control.\n");
> +		return;
> +	}
> +
> +	if (hw->mac.ops.set_ethertype_anti_spoofing) {
> +		IXGBE_WRITE_REG(hw, IXGBE_ETQF(i),
> +				(IXGBE_ETQF_FILTER_EN |
> +				IXGBE_ETQF_TX_ANTISPOOF |
> +				IXGBE_ETHERTYPE_FLOW_CTRL));
> +
> +		vf_num = dev_num_vf(eth_dev);
> +		for (i = 0; i < vf_num; i++) {
> +			hw->mac.ops.set_ethertype_anti_spoofing(hw, true, i);
> +		}
> +	}
ixgbe_set_ethertype_anti_spoofing() is exposed by ixgbe_api.h, and can be used directly.
I think we need a return value for above function, and then the caller can check it.
If it fails, does it need to return out, or just skip the failure?
In addition, is this operation only for x550, right? If yes, it may need a check above.

Regards,
Helin

> +
> +	return;
> +}
> +
>  int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)  {
>  	uint32_t vtctl, fcrth;
> @@ -262,6 +303,8 @@ int ixgbe_pf_host_configure(struct rte_eth_dev
> *eth_dev)
>  		IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(i), fcrth);
>  	}
> 
> +	ixgbe_add_tx_flow_control_drop_filter(eth_dev);
> +
>  	return 0;
>  }
> 
> --
> 1.9.3

Re: [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs

[Lu, Wenzhuo]

Hi Helin,

> -----Original Message-----
> From: Zhang, Helin
> Sent: Friday, October 23, 2015 10:49 AM
> To: Lu, Wenzhuo; dev@dpdk.org
> Subject: RE: [PATCH v2] ixgbe: Drop flow control frames from VFs
> 
> 
> 
> > -----Original Message-----
> > From: Lu, Wenzhuo
> > Sent: Thursday, October 22, 2015 3:34 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Helin; Lu, Wenzhuo
> > Subject: [PATCH v2] ixgbe: Drop flow control frames from VFs
> >
> > This patch will drop flow control frames from being transmitted from VSIs.
> > With this patch in place a malicious VF cannot send flow control or
> > PFC packets out on the wire.
> >
> > V2:
> > Reword the comments.
> >
> > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> > ---
> >  drivers/net/ixgbe/ixgbe_pf.c | 43
> > +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_pf.c
> > b/drivers/net/ixgbe/ixgbe_pf.c index
> > fd1c4ca..b33f4e9 100644
> > --- a/drivers/net/ixgbe/ixgbe_pf.c
> > +++ b/drivers/net/ixgbe/ixgbe_pf.c
> > @@ -55,6 +55,7 @@
> >  #define IXGBE_MAX_VFTA     (128)
> >  #define IXGBE_VF_MSG_SIZE_DEFAULT 1
> >  #define IXGBE_VF_GET_QUEUE_MSG_SIZE 5
> > +#define IXGBE_ETHERTYPE_FLOW_CTRL 0x8808
> >
> >  static inline uint16_t
> >  dev_num_vf(struct rte_eth_dev *eth_dev) @@ -166,6 +167,46 @@ void
> > ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
> >  	*vfinfo = NULL;
> >  }
> >
> > +static void
> > +ixgbe_add_tx_flow_control_drop_filter(struct rte_eth_dev *eth_dev) {
> > +	struct ixgbe_hw *hw =
> > +		IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
> > +	struct ixgbe_filter_info *filter_info =
> > +		IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data-
> >dev_private);
> > +	uint16_t vf_num;
> > +	int i;
> > +
> > +	/* occupy an entity of ether type filter */
> > +	for (i = 0; i < IXGBE_MAX_ETQF_FILTERS; i++) {
> > +		if (!(filter_info->ethertype_mask & (1 << i))) {
> > +			filter_info->ethertype_mask |= 1 << i;
> > +			filter_info->ethertype_filters[i] =
> > +				IXGBE_ETHERTYPE_FLOW_CTRL;
> > +			break;
> > +		}
> > +	}
> > +	if (i == IXGBE_MAX_ETQF_FILTERS) {
> > +		RTE_LOG(ERR, PMD, "Cannot find an unused ether type
> filter"
> > +				" entity for flow control.\n");
> > +		return;
> > +	}
> > +
> > +	if (hw->mac.ops.set_ethertype_anti_spoofing) {
> > +		IXGBE_WRITE_REG(hw, IXGBE_ETQF(i),
> > +				(IXGBE_ETQF_FILTER_EN |
> > +				IXGBE_ETQF_TX_ANTISPOOF |
> > +				IXGBE_ETHERTYPE_FLOW_CTRL));
> > +
> > +		vf_num = dev_num_vf(eth_dev);
> > +		for (i = 0; i < vf_num; i++) {
> > +			hw->mac.ops.set_ethertype_anti_spoofing(hw, true,
> i);
> > +		}
> > +	}
> ixgbe_set_ethertype_anti_spoofing() is exposed by ixgbe_api.h, and can be
> used directly.
> I think we need a return value for above function, and then the caller can
> check it.
> If it fails, does it need to return out, or just skip the failure?
For it's an additional check, I don't want to let it break the normal process.
If there's a failure (suppose not, because it's executed during init, there should
be enough ether type entities.), only output error log.

> In addition, is this operation only for x550, right? If yes, it may need a check
> above.
It's depends on if this NIC supports this function " hw->mac.ops.set_ethertype_anti_spoofing",
If some new ixgbe NICs can support it in future, we need not change the code.
But seems I should check it first to avoid occupy a ethertype_filter entity without using it. I'll send a V2.

> 
> Regards,
> Helin
> 
> > +
> > +	return;
> > +}
> > +
> >  int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)  {
> >  	uint32_t vtctl, fcrth;
> > @@ -262,6 +303,8 @@ int ixgbe_pf_host_configure(struct rte_eth_dev
> > *eth_dev)
> >  		IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(i), fcrth);
> >  	}
> >
> > +	ixgbe_add_tx_flow_control_drop_filter(eth_dev);
> > +
> >  	return 0;
> >  }
> >
> > --
> > 1.9.3

[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Wenzhuo Lu]

This patch will drop flow control frames from being transmitted
from VSIs.
With this patch in place a malicious VF cannot send flow control
or PFC packets out on the wire.

V2:
Reword the comments.

V3:
Move the check of set_ethertype_anti_spoofing to the top of the function,
to avoid occupying an ethertype_filter entity without using it.

V4:
Remove the useless braces and return.

Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
---
 drivers/net/ixgbe/ixgbe_pf.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index fd1c4ca..2ffbd1f 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -55,6 +55,7 @@
 #define IXGBE_MAX_VFTA     (128)
 #define IXGBE_VF_MSG_SIZE_DEFAULT 1
 #define IXGBE_VF_GET_QUEUE_MSG_SIZE 5
+#define IXGBE_ETHERTYPE_FLOW_CTRL 0x8808
 
 static inline uint16_t
 dev_num_vf(struct rte_eth_dev *eth_dev)
@@ -166,6 +167,47 @@ void ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
 	*vfinfo = NULL;
 }
 
+static void
+ixgbe_add_tx_flow_control_drop_filter(struct rte_eth_dev *eth_dev)
+{
+	struct ixgbe_hw *hw =
+		IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+	struct ixgbe_filter_info *filter_info =
+		IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data->dev_private);
+	uint16_t vf_num;
+	int i;
+
+	if (!hw->mac.ops.set_ethertype_anti_spoofing) {
+		RTE_LOG(INFO, PMD, "ether type anti-spoofing is not"
+			" supported.\n");
+		return;
+	}
+
+	/* occupy an entity of ether type filter */
+	for (i = 0; i < IXGBE_MAX_ETQF_FILTERS; i++) {
+		if (!(filter_info->ethertype_mask & (1 << i))) {
+			filter_info->ethertype_mask |= 1 << i;
+			filter_info->ethertype_filters[i] =
+				IXGBE_ETHERTYPE_FLOW_CTRL;
+			break;
+		}
+	}
+	if (i == IXGBE_MAX_ETQF_FILTERS) {
+		RTE_LOG(ERR, PMD, "Cannot find an unused ether type filter"
+			" entity for flow control.\n");
+		return;
+	}
+
+	IXGBE_WRITE_REG(hw, IXGBE_ETQF(i),
+			(IXGBE_ETQF_FILTER_EN |
+			IXGBE_ETQF_TX_ANTISPOOF |
+			IXGBE_ETHERTYPE_FLOW_CTRL));
+
+	vf_num = dev_num_vf(eth_dev);
+	for (i = 0; i < vf_num; i++)
+		hw->mac.ops.set_ethertype_anti_spoofing(hw, true, i);
+}
+
 int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 {
 	uint32_t vtctl, fcrth;
@@ -262,6 +304,8 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 		IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(i), fcrth);
 	}
 
+	ixgbe_add_tx_flow_control_drop_filter(eth_dev);
+
 	return 0;
 }
 
-- 
1.9.3

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

> -----Original Message-----
> From: Lu, Wenzhuo
> Sent: Friday, October 23, 2015 1:52 PM
> To: dev@dpdk.org
> Cc: Zhang, Helin; Lu, Wenzhuo
> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> 
> This patch will drop flow control frames from being transmitted from VSIs.
> With this patch in place a malicious VF cannot send flow control or PFC packets
> out on the wire.
> 
> V2:
> Reword the comments.
> 
> V3:
> Move the check of set_ethertype_anti_spoofing to the top of the function, to
> avoid occupying an ethertype_filter entity without using it.
> 
> V4:
> Remove the useless braces and return.
> 
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Vladislav Zolotarov]

On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Lu, Wenzhuo
> > Sent: Friday, October 23, 2015 1:52 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Helin; Lu, Wenzhuo
> > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> >
> > This patch will drop flow control frames from being transmitted from
VSIs.
> > With this patch in place a malicious VF cannot send flow control or PFC
packets
> > out on the wire.

The whole idea of this (and similar i40e patches sent before) is really
confusing.
If u want to disable FC feature for VFs then go and disable the feature.
Why keep (not malicious) user think that he/she has enabled the feature
while u silently block it?


> >
> > V2:
> > Reword the comments.
> >
> > V3:
> > Move the check of set_ethertype_anti_spoofing to the top of the
function, to
> > avoid occupying an ethertype_filter entity without using it.
> >
> > V4:
> > Remove the useless braces and return.
> >
> > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] 
Sent: Friday, October 23, 2015 2:24 PM
To: Zhang, Helin
Cc: Lu, Wenzhuo; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs


On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Lu, Wenzhuo
> > Sent: Friday, October 23, 2015 1:52 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Helin; Lu, Wenzhuo
> > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> >
> > This patch will drop flow control frames from being transmitted from VSIs.
> > With this patch in place a malicious VF cannot send flow control or PFC packets
> > out on the wire.
The whole idea of this (and similar i40e patches sent before) is really confusing. 
If u want to disable FC feature for VFs then go and disable the feature. Why keep (not malicious) user think that he/she has enabled the feature while u silently block it? 

Helin: I don't think disabling FC is equal to filtering out any pause frames. How about the software application constructs a pause frame and then tries to send it out?

> >
> > V2:
> > Reword the comments.
> >
> > V3:
> > Move the check of set_ethertype_anti_spoofing to the top of the function, to
> > avoid occupying an ethertype_filter entity without using it.
> >
> > V4:
> > Remove the useless braces and return.
> >
> > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Vladislav Zolotarov]

On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>
>
>
> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Friday, October 23, 2015 2:24 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from
VFs
>
>
> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Lu, Wenzhuo
> > > Sent: Friday, October 23, 2015 1:52 PM
> > > To: dev@dpdk.org
> > > Cc: Zhang, Helin; Lu, Wenzhuo
> > > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> > >
> > > This patch will drop flow control frames from being transmitted from
VSIs.
> > > With this patch in place a malicious VF cannot send flow control or
PFC packets
> > > out on the wire.
> The whole idea of this (and similar i40e patches sent before) is really
confusing.
> If u want to disable FC feature for VFs then go and disable the feature.
Why keep (not malicious) user think that he/she has enabled the feature
while u silently block it?
>
> Helin: I don't think disabling FC is equal to filtering out any pause
frames. How about the software application constructs a pause frame and
then tries to send it out?

But not disabling FC for the user and silently preventing it is bogus.
First, the conventional user should not be affected. I think this patch
(and all its clones) should be extended to, first, disable the FC Tx
feature for the relevant devices and only then adding any anti malicious
filtering.

>
> > >
> > > V2:
> > > Reword the comments.
> > >
> > > V3:
> > > Move the check of set_ethertype_anti_spoofing to the top of the
function, to
> > > avoid occupying an ethertype_filter entity without using it.
> > >
> > > V4:
> > > Remove the useless braces and return.
> > >
> > > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> > Acked-by: Helin Zhang <helin.zhang@intel.com>
> >

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] 
Sent: Friday, October 23, 2015 2:57 PM
To: Zhang, Helin
Cc: Lu, Wenzhuo; dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs


On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>
>
>
> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Friday, October 23, 2015 2:24 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
>
>
> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Lu, Wenzhuo
> > > Sent: Friday, October 23, 2015 1:52 PM
> > > To: dev@dpdk.org
> > > Cc: Zhang, Helin; Lu, Wenzhuo
> > > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> > >
> > > This patch will drop flow control frames from being transmitted from VSIs.
> > > With this patch in place a malicious VF cannot send flow control or PFC packets
> > > out on the wire.
> The whole idea of this (and similar i40e patches sent before) is really confusing.
> If u want to disable FC feature for VFs then go and disable the feature. Why keep (not malicious) user think that he/she has enabled the feature while u silently block it?
>
> Helin: I don't think disabling FC is equal to filtering out any pause frames. How about the software application constructs a pause frame and then tries to send it out?
But not disabling FC for the user and silently preventing it is bogus. First, the conventional user should not be affected. I think this patch (and all its clones) should be extended to, first, disable the FC Tx feature for the relevant devices and only then adding any anti malicious filtering. 
 
Helin: Disabling FC will disable both PF and VF FC, I don't find out where can disable VF FC only. Am I wrong?

>
> > >
> > > V2:
> > > Reword the comments.
> > >
> > > V3:
> > > Move the check of set_ethertype_anti_spoofing to the top of the function, to
> > > avoid occupying an ethertype_filter entity without using it.
> > >
> > > V4:
> > > Remove the useless braces and return.
> > >
> > > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> > Acked-by: Helin Zhang <helin.zhang@intel.com>
> >

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Vlad Zolotarov]

On 10/23/15 10:14, Zhang, Helin wrote:
>
> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Friday, October 23, 2015 2:57 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
>
>
> On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>>
>>
>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
>> Sent: Friday, October 23, 2015 2:24 PM
>> To: Zhang, Helin
>> Cc: Lu, Wenzhuo; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
>>
>>
>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Lu, Wenzhuo
>>>> Sent: Friday, October 23, 2015 1:52 PM
>>>> To: dev@dpdk.org
>>>> Cc: Zhang, Helin; Lu, Wenzhuo
>>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
>>>>
>>>> This patch will drop flow control frames from being transmitted from VSIs.
>>>> With this patch in place a malicious VF cannot send flow control or PFC packets
>>>> out on the wire.
>> The whole idea of this (and similar i40e patches sent before) is really confusing.
>> If u want to disable FC feature for VFs then go and disable the feature. Why keep (not malicious) user think that he/she has enabled the feature while u silently block it?
>>
>> Helin: I don't think disabling FC is equal to filtering out any pause frames. How about the software application constructs a pause frame and then tries to send it out?
> But not disabling FC for the user and silently preventing it is bogus. First, the conventional user should not be affected. I think this patch (and all its clones) should be extended to, first, disable the FC Tx feature for the relevant devices and only then adding any anti malicious filtering.
>   
> Helin: Disabling FC will disable both PF and VF FC, I don't find out where can disable VF FC only. Am I wrong?

There are flow_ctrl_get/set callbacks in eth_dev_ops which are used for 
configuring FC.
I see that they are not set for either ixgbevf or i40evf, so here we are 
all set for these.

>
>>>> V2:
>>>> Reword the comments.
>>>>
>>>> V3:
>>>> Move the check of set_ethertype_anti_spoofing to the top of the function, to
>>>> avoid occupying an ethertype_filter entity without using it.
>>>>
>>>> V4:
>>>> Remove the useless braces and return.
>>>>
>>>> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
>>> Acked-by: Helin Zhang <helin.zhang@intel.com>
>>>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

> -----Original Message-----
> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Friday, October 23, 2015 4:27 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> 
> 
> 
> On 10/23/15 10:14, Zhang, Helin wrote:
> >
> > From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> > Sent: Friday, October 23, 2015 2:57 PM
> > To: Zhang, Helin
> > Cc: Lu, Wenzhuo; dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> > from VFs
> >
> >
> > On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
> >>
> >>
> >> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> >> Sent: Friday, October 23, 2015 2:24 PM
> >> To: Zhang, Helin
> >> Cc: Lu, Wenzhuo; dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> >> from VFs
> >>
> >>
> >> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Lu, Wenzhuo
> >>>> Sent: Friday, October 23, 2015 1:52 PM
> >>>> To: dev@dpdk.org
> >>>> Cc: Zhang, Helin; Lu, Wenzhuo
> >>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> >>>>
> >>>> This patch will drop flow control frames from being transmitted from VSIs.
> >>>> With this patch in place a malicious VF cannot send flow control or
> >>>> PFC packets out on the wire.
> >> The whole idea of this (and similar i40e patches sent before) is really
> confusing.
> >> If u want to disable FC feature for VFs then go and disable the feature. Why
> keep (not malicious) user think that he/she has enabled the feature while u
> silently block it?
> >>
> >> Helin: I don't think disabling FC is equal to filtering out any pause frames. How
> about the software application constructs a pause frame and then tries to send it
> out?
> > But not disabling FC for the user and silently preventing it is bogus. First, the
> conventional user should not be affected. I think this patch (and all its clones)
> should be extended to, first, disable the FC Tx feature for the relevant devices
> and only then adding any anti malicious filtering.
> >
> > Helin: Disabling FC will disable both PF and VF FC, I don't find out where can
> disable VF FC only. Am I wrong?
> 
> There are flow_ctrl_get/set callbacks in eth_dev_ops which are used for
> configuring FC.
> I see that they are not set for either ixgbevf or i40evf, so here we are all set for
> these.
Helin: The behaviors rely on the hardware capability, but not the SW.
I meant I don't think it can support disabling VF FC. Please correct me in case I am wrong!


> 
> >
> >>>> V2:
> >>>> Reword the comments.
> >>>>
> >>>> V3:
> >>>> Move the check of set_ethertype_anti_spoofing to the top of the function,
> to
> >>>> avoid occupying an ethertype_filter entity without using it.
> >>>>
> >>>> V4:
> >>>> Remove the useless braces and return.
> >>>>
> >>>> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> >>> Acked-by: Helin Zhang <helin.zhang@intel.com>
> >>>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Vlad Zolotarov]

On 10/23/15 11:32, Zhang, Helin wrote:
>
>> -----Original Message-----
>> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
>> Sent: Friday, October 23, 2015 4:27 PM
>> To: Zhang, Helin
>> Cc: Lu, Wenzhuo; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
>>
>>
>>
>> On 10/23/15 10:14, Zhang, Helin wrote:
>>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
>>> Sent: Friday, October 23, 2015 2:57 PM
>>> To: Zhang, Helin
>>> Cc: Lu, Wenzhuo; dev@dpdk.org
>>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
>>> from VFs
>>>
>>>
>>> On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>>>>
>>>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
>>>> Sent: Friday, October 23, 2015 2:24 PM
>>>> To: Zhang, Helin
>>>> Cc: Lu, Wenzhuo; dev@dpdk.org
>>>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
>>>> from VFs
>>>>
>>>>
>>>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lu, Wenzhuo
>>>>>> Sent: Friday, October 23, 2015 1:52 PM
>>>>>> To: dev@dpdk.org
>>>>>> Cc: Zhang, Helin; Lu, Wenzhuo
>>>>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
>>>>>>
>>>>>> This patch will drop flow control frames from being transmitted from VSIs.
>>>>>> With this patch in place a malicious VF cannot send flow control or
>>>>>> PFC packets out on the wire.
>>>> The whole idea of this (and similar i40e patches sent before) is really
>> confusing.
>>>> If u want to disable FC feature for VFs then go and disable the feature. Why
>> keep (not malicious) user think that he/she has enabled the feature while u
>> silently block it?
>>>> Helin: I don't think disabling FC is equal to filtering out any pause frames. How
>> about the software application constructs a pause frame and then tries to send it
>> out?
>>> But not disabling FC for the user and silently preventing it is bogus. First, the
>> conventional user should not be affected. I think this patch (and all its clones)
>> should be extended to, first, disable the FC Tx feature for the relevant devices
>> and only then adding any anti malicious filtering.
>>> Helin: Disabling FC will disable both PF and VF FC, I don't find out where can
>> disable VF FC only. Am I wrong?
>>
>> There are flow_ctrl_get/set callbacks in eth_dev_ops which are used for
>> configuring FC.
>> I see that they are not set for either ixgbevf or i40evf, so here we are all set for
>> these.
> Helin: The behaviors rely on the hardware capability, but not the SW.
> I meant I don't think it can support disabling VF FC. Please correct me in case I am wrong!

I see. After a shallow sweep on the x540 and xl710 specs it seems that u 
r right. However I was talking about the SW interface only and since it 
is not enabled for the devices in question my whole objection is removed.

thanks,
vlad

>
>
>>>>>> V2:
>>>>>> Reword the comments.
>>>>>>
>>>>>> V3:
>>>>>> Move the check of set_ethertype_anti_spoofing to the top of the function,
>> to
>>>>>> avoid occupying an ethertype_filter entity without using it.
>>>>>>
>>>>>> V4:
>>>>>> Remove the useless braces and return.
>>>>>>
>>>>>> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
>>>>> Acked-by: Helin Zhang <helin.zhang@intel.com>
>>>>>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

> -----Original Message-----
> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Friday, October 23, 2015 5:00 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> 
> 
> 
> On 10/23/15 11:32, Zhang, Helin wrote:
> >
> >> -----Original Message-----
> >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> >> Sent: Friday, October 23, 2015 4:27 PM
> >> To: Zhang, Helin
> >> Cc: Lu, Wenzhuo; dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> >> from VFs
> >>
> >>
> >>
> >> On 10/23/15 10:14, Zhang, Helin wrote:
> >>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> >>> Sent: Friday, October 23, 2015 2:57 PM
> >>> To: Zhang, Helin
> >>> Cc: Lu, Wenzhuo; dev@dpdk.org
> >>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> >>> from VFs
> >>>
> >>>
> >>> On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
> >>>>
> >>>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com]
> >>>> Sent: Friday, October 23, 2015 2:24 PM
> >>>> To: Zhang, Helin
> >>>> Cc: Lu, Wenzhuo; dev@dpdk.org
> >>>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> >>>> from VFs
> >>>>
> >>>>
> >>>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote:
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Lu, Wenzhuo
> >>>>>> Sent: Friday, October 23, 2015 1:52 PM
> >>>>>> To: dev@dpdk.org
> >>>>>> Cc: Zhang, Helin; Lu, Wenzhuo
> >>>>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> >>>>>>
> >>>>>> This patch will drop flow control frames from being transmitted from
> VSIs.
> >>>>>> With this patch in place a malicious VF cannot send flow control
> >>>>>> or PFC packets out on the wire.
> >>>> The whole idea of this (and similar i40e patches sent before) is
> >>>> really
> >> confusing.
> >>>> If u want to disable FC feature for VFs then go and disable the
> >>>> feature. Why
> >> keep (not malicious) user think that he/she has enabled the feature
> >> while u silently block it?
> >>>> Helin: I don't think disabling FC is equal to filtering out any
> >>>> pause frames. How
> >> about the software application constructs a pause frame and then
> >> tries to send it out?
> >>> But not disabling FC for the user and silently preventing it is
> >>> bogus. First, the
> >> conventional user should not be affected. I think this patch (and all
> >> its clones) should be extended to, first, disable the FC Tx feature
> >> for the relevant devices and only then adding any anti malicious filtering.
> >>> Helin: Disabling FC will disable both PF and VF FC, I don't find out
> >>> where can
> >> disable VF FC only. Am I wrong?
> >>
> >> There are flow_ctrl_get/set callbacks in eth_dev_ops which are used
> >> for configuring FC.
> >> I see that they are not set for either ixgbevf or i40evf, so here we
> >> are all set for these.
> > Helin: The behaviors rely on the hardware capability, but not the SW.
> > I meant I don't think it can support disabling VF FC. Please correct me in case I
> am wrong!
> 
> I see. After a shallow sweep on the x540 and xl710 specs it seems that u r right.
> However I was talking about the SW interface only and since it is not enabled for
> the devices in question my whole objection is removed.
> 
> thanks,
> vlad

Vlad, thank you very much!
The best way for this issue is to do that in hardware, but now we need a fix/workaround.
It is really good to have the discussion with you, and clarify a lot. I think it can also remove a lot of questions from others. Thank you!

Regards,
Helin

> 
> >
> >
> >>>>>> V2:
> >>>>>> Reword the comments.
> >>>>>>
> >>>>>> V3:
> >>>>>> Move the check of set_ethertype_anti_spoofing to the top of the
> >>>>>> function,
> >> to
> >>>>>> avoid occupying an ethertype_filter entity without using it.
> >>>>>>
> >>>>>> V4:
> >>>>>> Remove the useless braces and return.
> >>>>>>
> >>>>>> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> >>>>> Acked-by: Helin Zhang <helin.zhang@intel.com>
> >>>>>

Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Thomas Monjalon]

> > This patch will drop flow control frames from being transmitted from VSIs.
> > With this patch in place a malicious VF cannot send flow control or PFC packets
> > out on the wire.
> > 
> > V2:
> > Reword the comments.
> > 
> > V3:
> > Move the check of set_ethertype_anti_spoofing to the top of the function, to
> > avoid occupying an ethertype_filter entity without using it.
> > 
> > V4:
> > Remove the useless braces and return.
> > 
> > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>

Applied, thanks