From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751665AbdJXWHa (ORCPT ); Tue, 24 Oct 2017 18:07:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59052 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751277AbdJXWH0 (ORCPT ); Tue, 24 Oct 2017 18:07:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 93E467E421 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=alex.williamson@redhat.com Date: Wed, 25 Oct 2017 00:06:54 +0200 From: Alex Williamson To: "Wang, Liang-min" Cc: "Kirsher, Jeffrey T" , "kvm@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "bhelgaas@google.com" , "Duyck, Alexander H" Subject: Re: [PATCH] Enable SR-IOV instantiation through /sys file Message-ID: <20171025000654.7621b84e@t450s.home> In-Reply-To: References: <20171024200426.62811-1-jeffrey.t.kirsher@intel.com> <20171024234351.0af0ff4a@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 24 Oct 2017 22:07:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Oct 2017 21:49:15 +0000 "Wang, Liang-min" wrote: > Just like any PCIe devices that supports SR-IOV. There are restrictions set for VF. Also, there is a concept of trust VF now available for PF to manage certain features that only selected VF could exercise. Are you saying all the devices supporting SR-IOV all have security issue? Here's a simple example, most SR-IOV capable NICs, including those from Intel, require the PF interface to be up in order to route traffic from the VF. If the user controls the PF interface and VFs are used elsewhere in the host, the PF driver in userspace can induce a denial of service on the VFs. That doesn't even take into account that VFs might be in separate IOMMU groups from the PF and therefore not isolated from the host like the PF and that the PF driver can potentially manipulate the VF, possibly performing DMA on behalf of the PF. VFs are only considered secure today because the PF is managed by a driver in the host kernel. Allowing simple enablement of VFs for a user owned PF seems inherently insecure to me. Thanks, Alex