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 B1227A04FA; Wed, 5 Feb 2020 15:13:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 914A61C0B9; Wed, 5 Feb 2020 15:13:24 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id F3AD31C014 for ; Wed, 5 Feb 2020 15:13:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580912002; 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=RA1q163tSFNoE4JSzx/Wt2GVMECMjZ7C0brv5EqYlAE=; b=KycEWxFbJ5Z8QfwisEM6rzMPF+OphzXpXvtvZEdFcy0RPw+FUBtZyjUzYNrXUop8cACnlL Wvafh5prwjb9cTlmZxtxZKnH6m3t70LFX4oLo+Ms75UPF0gqueO7NSkwGq5KUe6sRIu71V jNme/5aJ1AmtC8qtMjBLx81zcSPQl9Y= 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-424-CTlUFyNKOzCsy256PkLXAg-1; Wed, 05 Feb 2020 09:13:18 -0500 X-MC-Unique: CTlUFyNKOzCsy256PkLXAg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1D30B8018A1; Wed, 5 Feb 2020 14:13:17 +0000 (UTC) Received: from x1.home (ovpn-116-28.phx2.redhat.com [10.3.116.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3CC92100164D; Wed, 5 Feb 2020 14:13:16 +0000 (UTC) Date: Wed, 5 Feb 2020 07:13:15 -0700 From: Alex Williamson To: "Liu, Yi L" Cc: "kvm@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dev@dpdk.org" , "mtosatti@redhat.com" , "thomas@monjalon.net" , "bluca@debian.org" , "jerinjacobk@gmail.com" , "Richardson, Bruce" , "cohuck@redhat.com" Message-ID: <20200205071315.0569ed9e@x1.home> In-Reply-To: References: <158085337582.9445.17682266437583505502.stgit@gimli.home> <158085756068.9445.6284766069491778316.stgit@gimli.home> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Subject: Re: [dpdk-dev] [RFC PATCH 3/7] vfio/pci: Introduce VF token 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 Wed, 5 Feb 2020 07:57:29 +0000 "Liu, Yi L" wrote: > > From: Alex Williamson > > Sent: Wednesday, February 5, 2020 7:06 AM > > To: kvm@vger.kernel.org > > Subject: [RFC PATCH 3/7] vfio/pci: Introduce VF token > > > > If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not > > fully isolated from the PF. The PF can always cause a denial of > > service to the VF, if not access data passed through the VF directly. > > This is why vfio-pci currently does not bind to PFs with SR-IOV enabled > > and does not provide access itself to enabling SR-IOV on a PF. The > > IOMMU grouping mechanism might allow us a solution to this lack of > > isolation, however the deficiency isn't actually in the DMA path, so > > much as the potential cooperation between PF and VF devices. Also, > > if we were to force VFs into the same IOMMU group as the PF, we severely > > limit the utility of having independent drivers managing PFs and VFs > > with vfio. > > > > Therefore we introduce the concept of a VF token. The token is > > implemented as a UUID and represents a shared secret which must be set > > by the PF driver and used by the VF drivers in order to access a vfio > > device file descriptor for the VF. The ioctl to set the VF token will > > be provided in a later commit, this commit implements the underlying > > infrastructure. The concept here is to augment the string the user > > passes to match a device within a group in order to retrieve access to > > the device descriptor. For example, rather than passing only the PCI > > device name (ex. "0000:03:00.0") the user would also pass a vf_token > > UUID (ex. "2ab74924-c335-45f4-9b16-8569e5b08258"). The device match > > string therefore becomes: > > > > "0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258" > > > > This syntax is expected to be extensible to future options as well, with > > the standard being: > > > > "$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2" > > > > The device name must be first and option=value pairs are separated by > > spaces. > > > > The vf_token option is only required for VFs where the PF device is > > bound to vfio-pci. There is no change for PFs using existing host > > drivers. > > > > Note that in order to protect existing VF users, not only is it required > > to set a vf_token on the PF before VFs devices can be accessed, but also > > if there are existing VF users, (re)opening the PF device must also > > provide the current vf_token as authentication. This is intended to > > prevent a VF driver starting with a trusted PF driver and later being > > replaced by an unknown driver. A vf_token is not required to open the > > PF device when none of the VF devices are in use by vfio-pci drivers. > > So vfio_token is a kind of per-PF token? Yes, the token is per-PF. Note that the token can be changed and it does not "de-authenticate" opened VFs. Thanks, Alex