| Message ID | 1445579545-2430-1-git-send-email-wenzhuo.lu@intel.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id C1993C3F4; Fri, 23 Oct 2015 07:52:34 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 4228F924E for <dev@dpdk.org>; Fri, 23 Oct 2015 07:52:33 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 22 Oct 2015 22:52:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,185,1444719600"; d="scan'208";a="670075945" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by orsmga003.jf.intel.com with ESMTP; 22 Oct 2015 22:52:32 -0700 Received: from shecgisg004.sh.intel.com (shecgisg004.sh.intel.com [10.239.29.89]) by shvmail01.sh.intel.com with ESMTP id t9N5qUhg023744; Fri, 23 Oct 2015 13:52:30 +0800 Received: from shecgisg004.sh.intel.com (localhost [127.0.0.1]) by shecgisg004.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id t9N5qQkC002909; Fri, 23 Oct 2015 13:52:28 +0800 Received: (from wenzhuol@localhost) by shecgisg004.sh.intel.com (8.13.6/8.13.6/Submit) id t9N5qQg2002894; Fri, 23 Oct 2015 13:52:26 +0800 From: Wenzhuo Lu <wenzhuo.lu@intel.com> To: dev@dpdk.org Date: Fri, 23 Oct 2015 13:52:25 +0800 Message-Id: <1445579545-2430-1-git-send-email-wenzhuo.lu@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1444445798-23929-1-git-send-email-wenzhuo.lu@intel.com> References: <1444445798-23929-1-git-send-email-wenzhuo.lu@intel.com> Subject: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Wenzhuo Lu
Oct. 23, 2015, 5:52 a.m. UTC
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(+)
Comments
> -----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>
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> >
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> >
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> > >
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> > >
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> >>>
> -----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> > >>>
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> >>>>>
> -----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> > >>>>>
> > 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
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; }