From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id 946568D93 for ; Thu, 8 Oct 2015 16:53:51 +0200 (CEST) Received: by wicgb1 with SMTP id gb1so29370363wic.1 for ; Thu, 08 Oct 2015 07:53:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=PbE9qHZqSxJIMnooIjk8T8DSS/gQ/MvqB+P0pfIjZ+4=; b=bKqDw8ma5vfbM37E6Ff3l4Yh1Ksa6MudAkf/vJtVigp3LEmLxknf3nwmLb+KpVClLm HHhOvoeF+EM8UHItspbyvw6S2bB+LUDNfa1boqqa+HfLkc/6DGBKdxJCpdI1I7Zmbno+ JaFgBsqQUyuU1MKyusoMUWo+1tjkytmU/JZYGzbVLmxwRfK9IxORMA9571XAcYTcDwvq 6R45Bs4MlGYbXzTRU+hz9a9TKwuk7Pq9Uyg7wKdizB9uOZkWEK927aH07RpF+uxwnc77 EoYb0dzGGf9mUhGEZFCgVD/e0/4ky1YI4AyZaP7I+ukglu6qHuVWkQEQr2Xgxz14EcfD rSOg== X-Gm-Message-State: ALoCoQks2SQUC7iKJ/zjd0iGOXaKi9xjx6q+F5xUlSLh65sjz6AZ3wclVIAg4xglKHUKvaZuQnXC X-Received: by 10.195.13.14 with SMTP id eu14mr8652337wjd.9.1444316031395; Thu, 08 Oct 2015 07:53:51 -0700 (PDT) Received: from [10.0.0.171] ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id lb10sm46667920wjc.9.2015.10.08.07.53.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Oct 2015 07:53:50 -0700 (PDT) To: "Wu, Jingjing" References: <1443170678-7249-1-git-send-email-jingjing.wu@intel.com> <9BB6961774997848B5B42BEC655768F8CECC60@SHSMSX104.ccr.corp.intel.com> From: Vlad Zolotarov Message-ID: <5616837D.7030609@cloudius-systems.com> Date: Thu, 8 Oct 2015 17:53:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <9BB6961774997848B5B42BEC655768F8CECC60@SHSMSX104.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "Pei, Yulong" Subject: Re: [dpdk-dev] [PATCH] i40e: workaround for Security issue in SR-IOV mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 14:53:51 -0000 On 10/08/15 05:17, Wu, Jingjing wrote: >>> 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. >> This is a very strange approach - this would silently disable the Tx FC while a user would think it's enabled. Wouldn't the right approach be to let the user decide weather to enable this feature or even better - allow PF to disable this feature in the VF? > So, even we let VF sending Tx, it does not make sense at all. As my understanding, Flow control is used for full-duplex point-to-point connections. How about VF? What is its peer for the point-to-point connect? So if we enable it, it will be a security risk if attacker sends FC on VFs. I'll start start from the end: AFAIR FC frames are not forwarded, they only throttle the sender on the side that receives the PAUSE frame. Therefore it's quite trickery to create a PAUSE-frame attack as I see it - u'll have to hack the switch next to the host u attack. So, let's drop the "security" risk argument for now... ;) Regarding VF sending FC frames being useless: this depends on the setup demands. If drops in the VF on the MAC level are not acceptable then it makes the whole lot of sense, just like it makes sense with a PF in the same situation. Of course, as a result the whole (switch) link will be throttled however that's the price to pay and System Administrators should be well aware of it. If, on the other hand, System Administrator doesn't want FC it may just not enable it on this VF. If memory serves me well FC is disabled by default in DPDK. thanks, vlad > > Thanks > Jingjing