From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E31C9A04AE; Wed, 6 Nov 2019 23:33:13 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CBD521E8ED; Wed, 6 Nov 2019 23:33:12 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id D43FA1E8EC for ; Wed, 6 Nov 2019 23:33:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573079591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QtryUksG0nE5T3j0n6emfW8Vh+3Pw+woUYFyLra5qrE=; b=cbFTYf/CQiThOD4BRoMIbyLtG3ftClSMtOns4c5Mfg7nFqvQ2e4jQBBSMjqpu0ZvjYkUqG 15x6PyYbluTY7/PPnb1IYXC/n0nJuGq4fXoWDRtFxqe3smU4oB7Z1plIXKSMGr2bpeZbRM h7NqvveFu5K1uTvEs088Q3od78RkDFU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-133-yJSRfTlnMWSBzBK5hCQBRg-1; Wed, 06 Nov 2019 17:33:07 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 318831005500; Wed, 6 Nov 2019 22:33:05 +0000 (UTC) Received: from x1.home (ovpn-116-138.phx2.redhat.com [10.3.116.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id F238F600CD; Wed, 6 Nov 2019 22:32:50 +0000 (UTC) Date: Wed, 6 Nov 2019 15:32:50 -0700 From: Alex Williamson To: Thomas Monjalon Cc: dev@dpdk.org, Jerin Jacob Kollanukkaran , Vamsi Krishna Attunuru , arybchenko@solarflare.com, ferruh.yigit@intel.com, maxime.coquelin@redhat.com, Stephen Hemminger , bruce.richardson@intel.com, david.marchand@redhat.com, bluca@debian.org, Christian Ehrhardt , ktraynor@redhat.com, anatoly.burakov@intel.com, konstantin.ananyev@intel.com, honnappa.nagarahalli@arm.com, Liang-Min Wang , Alexander Duyck , Peter Xu , Eric Auger Message-ID: <20191106153250.77e63a38@x1.home> In-Reply-To: <1659615.GCIDYkGxRJ@xps> References: <20190906091230.13923-1-vattunuru@marvell.com> <1612178.XsdEgM4R2a@xps> <1659615.GCIDYkGxRJ@xps> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: yJSRfTlnMWSBzBK5hCQBRg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel module X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 31 Oct 2019 18:03:53 +0100 Thomas Monjalon wrote: > We don't get enough attention on this topic. > Let me rephrase the issue and the proposals with more people Cc'ed. >=20 > We are talking about SR-IOV VFs in VMs > with a PF managed on the host by DPDK. > The PF driver is either a (1) bifurcated (Mellanox case), > or (2) bound to UIO with igb_uio, or (3) bound to VFIO. >=20 > In case 1, the PF is still managed by a kernel driver, so no issue. >=20 > In case 2, the PF is managed by UIO. > There is no SR-IOV support in upstream UIO, > but the out-of-tree module igb_uio works. > However we would like to drop this legacy module from DPDK. > Some (most) Linux distributions do not package igb_uio anyway. > The other issue is that igb_uio is using physical addressing, > which is not acceptable with OCTEON TX2 for performance reason. >=20 > In case 3, the PF is managed by VFIO. This is the case we want to fix. > VFIO does not allow to create VFs. > The workaround is to create VFs before binding the PF to VFIO. > But since Linux 4.19, VFIO forbids any SR-IOV VF management. > There is a security concern about allowing userspace to manage SR-IOV > VF messages and taking the responsibility for VFs in the guest. >=20 > It is desired to allow the system admin deciding the security levels, > by adding a flag in VFIO "let me manage VFs, I know what I am doing". > Reference of "recent" discussion: https://lkml.org/lkml/2018/3/6/855 > For now, there is no upstream solution merged. >=20 > This patch is proposing a solution using an out-of-tree module. > In this case, the admin will decide explicitly to bind the PF to vfio_pf. > Unfortunately this solution won't work in environments which > forbid any out-of-tree module. > Another concern is that it looks like DPDK-only solution. >=20 > We have an issue but we do not want to propose a half-solution > which would harm other projects and users. > So the question is: > Do we accept this patch as a temporary solution? > Or can we get an agreement soon for an upstream kernel solution? >=20 > Thanks for reading and giving your (clear) opinion. I'm pretty appalled that anyone would consider shipping this module and actually claiming that it's supported in some way. Seriously, it's disturbing to see a driver that intentionally circumvents a security issue that we all seem to agree exists, but just hand wave that it doesn't apply to dpdk configurations. Ideas have been suggested upstream for for quarantining VFs generated from user owned PFs such that we require an opt-in to make use of them in this way. Nobody seems to be pursuing such ideas upstream. I don't even see upstream proposals to add a scary sounding module option to vfio-pci that would taint the kernel, but make this available. If nothing else, please remove the vfio name from this abomination, it has nothing to do with vfio other than to try to subvert the security and isolation that vfio attempts to provide. Thanks, Alex