Thread (35 messages) flat view 35 messages, 6 authors, 2013-12-10

Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)

From: Alex Williamson <hidden>
Date: 2013-12-10 05:53:29
Also in: linux-iommu, linux-pci, lkml

On Tue, 2013-12-10 at 05:37 +0000, Bharat.Bhushan@freescale.com wrote:
quoted
-----Original Message-----
From: Alex Williamson [mailto:alex.williamson@redhat.com]
Sent: Saturday, December 07, 2013 1:00 AM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linux-pci@vger.kernel.org; agraf@suse.de; Yoder
Stuart-B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)

On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote:
quoted
On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote:
quoted
quoted
-----Original Message-----
From: Wood Scott-B07421
Sent: Friday, December 06, 2013 5:52 AM
To: Bhushan Bharat-R65777
Cc: Alex Williamson; linux-pci@vger.kernel.org; agraf@suse.de;
Yoder Stuart- B08248; iommu@lists.linux-foundation.org;
bhelgaas@google.com; linuxppc- dev@lists.ozlabs.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
IOMMU (PAMU)

On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote:
quoted
quoted
-----Original Message-----
From: Bhushan Bharat-R65777
Sent: Wednesday, November 27, 2013 9:39 PM
To: 'Alex Williamson'
Cc: Wood Scott-B07421; linux-pci@vger.kernel.org;
agraf@suse.de; Yoder Stuart- B08248;
iommu@lists.linux-foundation.org; bhelgaas@google.com;
linuxppc- dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for
Freescale IOMMU (PAMU)

If we just provide the size of MSI bank to userspace then
userspace cannot do anything wrong.
So userspace does not know address, so it cannot mmap and cause
any
interference by directly reading/writing.

That's security through obscurity...  Couldn't the malicious user
find out the address via other means, such as experimentation on
another system over which they have full control?  What would
happen if the user reads from their device's PCI config space?  Or
gets the information via some back door in the PCI device they
own?  Or pokes throughout the address space looking for something that
generates an interrupt to its own device?
quoted
quoted
So how to solve this problem, Any suggestion ?

We have to map one window in PAMU for MSIs and a malicious user can
ask its device to do DMA to MSI window region with any pair of
address and data, which can lead to unexpected MSIs in system?
I don't think there are any solutions other than to limit each bank to
one user, unless the admin turns some knob that says they're OK with
the partial loss of isolation.
Even if the admin does opt-in to an allow_unsafe_interrupts options, it should
still be reasonably difficult for one guest to interfere with the other.  I
don't think we want to rely on the blind luck of making the full MSI bank
accessible to multiple guests and hoping they don't step on each other.
Not sure how to solve in this case (sharing MSI page)
quoted
 That probably means that vfio needs to manage the space rather than the guest.
What you mean by " vfio needs to manage the space rather than the guest"?
I mean there needs to be some kernel component managing the contents of
the MSI page rather than just handing it out to the user and hoping for
the best.  The user API also needs to remain the same whether the user
has the MSI page exclusively or it's shared with others (kernel or
users).  Thanks,

Alex
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help