From: Stefan Hajnoczi <stefanha@gmail.com>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Sun, Yi Y" <yi.y.sun@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"Wu, Hao" <hao.wu@intel.com>,
"Tian, Jun J" <jun.j.tian@intel.com>
Subject: Re: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs
Date: Mon, 22 Jun 2020 13:49:04 +0100 [thread overview]
Message-ID: <20200622124904.GA15683@stefanha-x1.localdomain> (raw)
In-Reply-To: <20200616170016.GC34820@otc-nc-03>
[-- Attachment #1.1: Type: text/plain, Size: 5729 bytes --]
On Tue, Jun 16, 2020 at 10:00:16AM -0700, Raj, Ashok wrote:
> On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote:
> > On Tue, Jun 16, 2020 at 02:26:38AM +0000, Tian, Kevin wrote:
> > > > From: Stefan Hajnoczi <stefanha@gmail.com>
> > > > Sent: Monday, June 15, 2020 6:02 PM
> > > >
> > > > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > > > > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > > > > Intel platforms allows address space sharing between device DMA and
> > > > > applications. SVA can reduce programming complexity and enhance
> > > > security.
> > > > >
> > > > > This VFIO series is intended to expose SVA usage to VMs. i.e. Sharing
> > > > > guest application address space with passthru devices. This is called
> > > > > vSVA in this series. The whole vSVA enabling requires QEMU/VFIO/IOMMU
> > > > > changes. For IOMMU and QEMU changes, they are in separate series (listed
> > > > > in the "Related series").
> > > > >
> > > > > The high-level architecture for SVA virtualization is as below, the key
> > > > > design of vSVA support is to utilize the dual-stage IOMMU translation (
> > > > > also known as IOMMU nesting translation) capability in host IOMMU.
> > > > >
> > > > >
> > > > > .-------------. .---------------------------.
> > > > > | vIOMMU | | Guest process CR3, FL only|
> > > > > | | '---------------------------'
> > > > > .----------------/
> > > > > | PASID Entry |--- PASID cache flush -
> > > > > '-------------' |
> > > > > | | V
> > > > > | | CR3 in GPA
> > > > > '-------------'
> > > > > Guest
> > > > > ------| Shadow |--------------------------|--------
> > > > > v v v
> > > > > Host
> > > > > .-------------. .----------------------.
> > > > > | pIOMMU | | Bind FL for GVA-GPA |
> > > > > | | '----------------------'
> > > > > .----------------/ |
> > > > > | PASID Entry | V (Nested xlate)
> > > > > '----------------\.------------------------------.
> > > > > | | |SL for GPA-HPA, default domain|
> > > > > | | '------------------------------'
> > > > > '-------------'
> > > > > Where:
> > > > > - FL = First level/stage one page tables
> > > > > - SL = Second level/stage two page tables
> > > >
> > > > Hi,
> > > > Looks like an interesting feature!
> > > >
> > > > To check I understand this feature: can applications now pass virtual
> > > > addresses to devices instead of translating to IOVAs?
> > > >
> > > > If yes, can guest applications restrict the vSVA address space so the
> > > > device only has access to certain regions?
> > > >
> > > > On one hand replacing IOVA translation with virtual addresses simplifies
> > > > the application programming model, but does it give up isolation if the
> > > > device can now access all application memory?
> > > >
> > >
> > > with SVA each application is allocated with a unique PASID to tag its
> > > virtual address space. The device that claims SVA support must guarantee
> > > that one application can only program the device to access its own virtual
> > > address space (i.e. all DMAs triggered by this application are tagged with
> > > the application's PASID, and are translated by IOMMU's PASID-granular
> > > page table). So, isolation is not sacrificed in SVA.
> >
> > Isolation between applications is preserved but there is no isolation
> > between the device and the application itself. The application needs to
> > trust the device.
>
> Right. With all convenience comes security trust. With SVA there is an
> expectation that the device has the required security boundaries properly
> implemented. FWIW, what is our guarantee today that VF's are secure from
> one another or even its own PF? They can also generate transactions with
> any of its peer id's and there is nothing an IOMMU can do today. Other than
> rely on ACS. Even BusMaster enable can be ignored and devices (malicious
> or otherwise) can generate after the BM=0. With SVM you get the benefits of
>
> * Not having to register regions
> * Don't need to pin application space for DMA.
As along as the security model is clearly documented users can decide
whether or not SVA meets their requirements. I just wanted to clarify
what the security model is.
>
> >
> > Examples:
> >
> > 1. The device can snoop secret data from readable pages in the
> > application's virtual memory space.
>
> Aren't there other security technologies that can address this?
Maybe the IOMMU could enforce Memory Protection Keys? Imagine each
device is assigned a subset of memory protection keys and the IOMMU
checks them on each device access. This would allow the application to
mark certain pages off-limits to the device but the IOMMU could still
walk the full process page table (no need to construct a special device
page table for the IOMMU).
> >
> > 2. The device can gain arbitrary execution on the CPU by overwriting
> > control flow addresses (e.g. function pointers, stack return
> > addresses) in writable pages.
>
> I suppose technology like CET might be able to guard. The general
> expectation is code pages and anything that needs to be protected should be
> mapped nor writable.
Function pointers are a common exception to this. They are often located
in writable heap or stack pages.
There might also be dynamic linker memory structures that are easy to
hijack.
Stefan
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
prev parent reply other threads:[~2020-06-22 12:49 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 12:15 [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs Liu Yi L
2020-06-11 12:15 ` [PATCH v2 01/15] vfio/type1: Refactor vfio_iommu_type1_ioctl() Liu Yi L
2020-06-11 12:15 ` [PATCH v2 02/15] iommu: Report domain nesting info Liu Yi L
2020-06-11 19:30 ` Alex Williamson
2020-06-12 9:05 ` Liu, Yi L
2020-06-15 1:22 ` Tian, Kevin
2020-06-15 6:04 ` Liu, Yi L
2020-06-16 1:56 ` Tian, Kevin
2020-06-16 2:24 ` Liu, Yi L
2020-06-17 14:39 ` Jean-Philippe Brucker
2020-06-18 11:46 ` Liu, Yi L
2020-06-11 12:15 ` [PATCH v2 03/15] vfio/type1: Report iommu nesting info to userspace Liu Yi L
2020-06-11 12:15 ` [PATCH v2 04/15] vfio: Add PASID allocation/free support Liu Yi L
2020-06-11 12:15 ` [PATCH v2 05/15] iommu/vt-d: Support setting ioasid set to domain Liu Yi L
2020-06-11 12:15 ` [PATCH v2 06/15] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free) Liu Yi L
2020-06-11 12:15 ` [PATCH v2 07/15] iommu/uapi: Add iommu_gpasid_unbind_data Liu Yi L
2020-06-11 12:15 ` [PATCH v2 08/15] iommu: Pass domain and unbind_data to sva_unbind_gpasid() Liu Yi L
2020-06-11 12:15 ` [PATCH v2 09/15] iommu/vt-d: Check ownership for PASIDs from user-space Liu Yi L
2020-06-11 12:15 ` [PATCH v2 10/15] vfio/type1: Support binding guest page tables to PASID Liu Yi L
2020-06-11 12:15 ` [PATCH v2 11/15] vfio/type1: Allow invalidating first-level/stage IOMMU cache Liu Yi L
2020-06-11 12:15 ` [PATCH v2 12/15] vfio/type1: Add vSVA support for IOMMU-backed mdevs Liu Yi L
2020-06-11 12:15 ` [PATCH v2 13/15] vfio/pci: Expose PCIe PASID capability to guest Liu Yi L
2020-06-11 12:15 ` [PATCH v2 14/15] vfio: Document dual stage control Liu Yi L
2020-06-15 9:41 ` Stefan Hajnoczi
2020-06-17 6:27 ` Liu, Yi L
2020-06-22 12:51 ` Stefan Hajnoczi
2020-06-23 6:43 ` Liu, Yi L
2020-06-11 12:15 ` [PATCH v2 15/15] iommu/vt-d: Support reporting nesting capability info Liu Yi L
2020-06-15 10:02 ` [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs Stefan Hajnoczi
2020-06-15 12:39 ` Liu, Yi L
2020-06-16 15:34 ` Stefan Hajnoczi
2020-06-16 2:26 ` Tian, Kevin
2020-06-16 15:49 ` Stefan Hajnoczi
2020-06-16 16:09 ` Peter Xu
2020-06-22 12:49 ` Stefan Hajnoczi
2020-06-16 17:00 ` Raj, Ashok
2020-06-22 12:49 ` Stefan Hajnoczi [this message]
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=20200622124904.GA15683@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=jun.j.tian@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.y.sun@intel.com \
/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).