From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
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,
bruce.richardson@intel.com, kevin.tian@intel.com
Subject: Re: [dpdk-dev] [PATCH v3 3/7] vfio/pci: Introduce VF token
Date: Thu, 19 Mar 2020 18:27:30 +0100 [thread overview]
Message-ID: <20200319182730.16f4c476.cohuck@redhat.com> (raw)
In-Reply-To: <158396393244.5601.10297430724964025753.stgit@gimli.home>
On Wed, 11 Mar 2020 15:58:52 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> 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, even if by simply resetting itself. The degree to which a PF
> can access the data passed through a VF or interfere with its operation
> is dependent on a given SR-IOV implementation. Therefore we want to
> avoid a scenario where an existing vfio-pci based userspace driver might
> assume the PF driver is trusted, for example assigning a PF to one VM
> and VF to another with some expectation of isolation. IOMMU grouping
> could be a solution to this, but imposes an unnecessarily strong
> relationship between PF and VF drivers if they need to operate with the
> same IOMMU context. Instead we introduce a "VF token", which is
> essentially just a shared secret between PF and VF drivers, implemented
> as a UUID.
>
> The VF token can be set by a vfio-pci based PF driver and must be known
> by the vfio-pci based VF driver in order to gain access to the device.
> This allows the degree to which this VF token is considered secret to be
> determined by the applications and environment. For example a VM might
> generate a random UUID known only internally to the hypervisor while a
> userspace networking appliance might use a shared, or even well know,
> UUID among the application drivers.
>
> To incorporate this VF token, the VFIO_GROUP_GET_DEVICE_FD interface is
> extended to accept key=value pairs in addition to the device name. This
> allows us to most easily deny user access to the device without risk
> that existing userspace drivers assume region offsets, IRQs, and other
> device features, leading to more elaborate error paths. The format of
> these options are expected to take the form:
>
> "$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2"
>
> Where the device name is always provided first for compatibility and
> additional options are specified in a space separated list. The
> relation between and requirements for the additional options will be
> vfio bus driver dependent, however unknown or unused option within this
> schema should return error. This allow for future use of unknown
> options as well as a positive indication to the user that an option is
> used.
>
> An example VF token option would take this form:
>
> "0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258"
>
> When accessing a VF where the PF is making use of vfio-pci, the user
> MUST provide the current vf_token. When accessing a PF, the user MUST
> provide the current vf_token IF there are active VF users or MAY provide
> a vf_token in order to set the current VF token when no VF users are
> active. The former requirement assures VF users that an unassociated
> driver cannot usurp the PF device. These semantics also imply that a
> VF token MUST be set by a PF driver before VF drivers can access their
> device, the default token is random and mechanisms to read the token are
> not provided in order to protect the VF token of previous users. Use of
> the vf_token option outside of these cases will return an error, as
> discussed above.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> drivers/vfio/pci/vfio_pci.c | 198 +++++++++++++++++++++++++++++++++++
> drivers/vfio/pci/vfio_pci_private.h | 8 +
> 2 files changed, 205 insertions(+), 1 deletion(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
next prev parent reply other threads:[~2020-03-19 17:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 21:58 [dpdk-dev] [PATCH v3 0/7] vfio/pci: SR-IOV support Alex Williamson
2020-03-11 21:58 ` [dpdk-dev] [PATCH v3 1/7] vfio: Include optional device match in vfio_device_ops callbacks Alex Williamson
2020-03-11 21:58 ` [dpdk-dev] [PATCH v3 2/7] vfio/pci: Implement match ops Alex Williamson
2020-03-11 21:58 ` [dpdk-dev] [PATCH v3 3/7] vfio/pci: Introduce VF token Alex Williamson
2020-03-19 17:27 ` Cornelia Huck [this message]
2020-03-11 21:59 ` [dpdk-dev] [PATCH v3 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user Alex Williamson
2020-03-19 17:33 ` Cornelia Huck
2020-03-11 21:59 ` [dpdk-dev] [PATCH v3 5/7] vfio/pci: Add sriov_configure support Alex Williamson
2020-03-19 17:44 ` Cornelia Huck
2020-03-11 21:59 ` [dpdk-dev] [PATCH v3 6/7] vfio/pci: Remove dev_fmt definition Alex Williamson
2020-03-11 21:59 ` [dpdk-dev] [PATCH v3 7/7] vfio/pci: Cleanup .probe() exit paths Alex Williamson
2020-03-19 17:46 ` Cornelia Huck
2020-03-19 6:32 ` [dpdk-dev] [PATCH v3 0/7] vfio/pci: SR-IOV support Tian, Kevin
2020-03-19 13:11 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200319182730.16f4c476.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=bluca@debian.org \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerinjacobk@gmail.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).