All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"Raj,  Ashok" <ashok.raj@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Sun,  Yi Y" <yi.y.sun@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
	"Tian, Jun J" <jun.j.tian@intel.com>
Subject: Re: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)
Date: Wed, 8 Jul 2020 13:54:44 -0600	[thread overview]
Message-ID: <20200708135444.4eac48a4@x1.home> (raw)
In-Reply-To: <DM5PR11MB1435B159DA10C8301B89A6F0C3670@DM5PR11MB1435.namprd11.prod.outlook.com>

On Wed, 8 Jul 2020 08:16:16 +0000
"Liu, Yi L" <yi.l.liu@intel.com> wrote:

> Hi Alex,
> 
> > From: Liu, Yi L < yi.l.liu@intel.com>
> > Sent: Friday, July 3, 2020 2:28 PM
> > 
> > Hi Alex,
> >   
> > > From: Alex Williamson <alex.williamson@redhat.com>
> > > Sent: Friday, July 3, 2020 5:19 AM
> > >
> > > On Wed, 24 Jun 2020 01:55:19 -0700
> > > Liu Yi L <yi.l.liu@intel.com> wrote:
> > >  
> > > > This patch allows user space to request PASID allocation/free, e.g.
> > > > when serving the request from the guest.
> > > >
> > > > PASIDs that are not freed by userspace are automatically freed when
> > > > the IOASID set is destroyed when process exits.  
> [...]
> > > > +static int vfio_iommu_type1_pasid_request(struct vfio_iommu *iommu,
> > > > +					  unsigned long arg)
> > > > +{
> > > > +	struct vfio_iommu_type1_pasid_request req;
> > > > +	unsigned long minsz;
> > > > +
> > > > +	minsz = offsetofend(struct vfio_iommu_type1_pasid_request, range);
> > > > +
> > > > +	if (copy_from_user(&req, (void __user *)arg, minsz))
> > > > +		return -EFAULT;
> > > > +
> > > > +	if (req.argsz < minsz || (req.flags & ~VFIO_PASID_REQUEST_MASK))
> > > > +		return -EINVAL;
> > > > +
> > > > +	if (req.range.min > req.range.max)  
> > >
> > > Is it exploitable that a user can spin the kernel for a long time in
> > > the case of a free by calling this with [0, MAX_UINT] regardless of their actual  
> > allocations?
> > 
> > IOASID can ensure that user can only free the PASIDs allocated to the user. but
> > it's true, kernel needs to loop all the PASIDs within the range provided by user. it
> > may take a long time. is there anything we can do? one thing may limit the range
> > provided by user?  
> 
> thought about it more, we have per-VM pasid quota (say 1000), so even if
> user passed down [0, MAX_UNIT], kernel will only loop the 1000 pasids at
> most. do you think we still need to do something on it?

How do you figure that?  vfio_iommu_type1_pasid_request() accepts the
user's min/max so long as (max > min) and passes that to
vfio_iommu_type1_pasid_free(), then to vfio_pasid_free_range()  which
loops as:

	ioasid_t pasid = min;
	for (; pasid <= max; pasid++)
		ioasid_free(pasid);

A user might only be able to allocate 1000 pasids, but apparently they
can ask to free all they want.

It's also not obvious to me that calling ioasid_free() is only allowing
the user to free their own passid.  Does it?  It would be a pretty
gaping hole if a user could free arbitrary pasids.  A r-b tree of
passids might help both for security and to bound spinning in a loop.
Thanks,

Alex

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: "eric.auger@redhat.com" <eric.auger@redhat.com>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"Tian, Jun J" <jun.j.tian@intel.com>,
	"Sun, Yi Y" <yi.y.sun@intel.com>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"Wu, Hao" <hao.wu@intel.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)
Date: Wed, 8 Jul 2020 13:54:44 -0600	[thread overview]
Message-ID: <20200708135444.4eac48a4@x1.home> (raw)
In-Reply-To: <DM5PR11MB1435B159DA10C8301B89A6F0C3670@DM5PR11MB1435.namprd11.prod.outlook.com>

On Wed, 8 Jul 2020 08:16:16 +0000
"Liu, Yi L" <yi.l.liu@intel.com> wrote:

> Hi Alex,
> 
> > From: Liu, Yi L < yi.l.liu@intel.com>
> > Sent: Friday, July 3, 2020 2:28 PM
> > 
> > Hi Alex,
> >   
> > > From: Alex Williamson <alex.williamson@redhat.com>
> > > Sent: Friday, July 3, 2020 5:19 AM
> > >
> > > On Wed, 24 Jun 2020 01:55:19 -0700
> > > Liu Yi L <yi.l.liu@intel.com> wrote:
> > >  
> > > > This patch allows user space to request PASID allocation/free, e.g.
> > > > when serving the request from the guest.
> > > >
> > > > PASIDs that are not freed by userspace are automatically freed when
> > > > the IOASID set is destroyed when process exits.  
> [...]
> > > > +static int vfio_iommu_type1_pasid_request(struct vfio_iommu *iommu,
> > > > +					  unsigned long arg)
> > > > +{
> > > > +	struct vfio_iommu_type1_pasid_request req;
> > > > +	unsigned long minsz;
> > > > +
> > > > +	minsz = offsetofend(struct vfio_iommu_type1_pasid_request, range);
> > > > +
> > > > +	if (copy_from_user(&req, (void __user *)arg, minsz))
> > > > +		return -EFAULT;
> > > > +
> > > > +	if (req.argsz < minsz || (req.flags & ~VFIO_PASID_REQUEST_MASK))
> > > > +		return -EINVAL;
> > > > +
> > > > +	if (req.range.min > req.range.max)  
> > >
> > > Is it exploitable that a user can spin the kernel for a long time in
> > > the case of a free by calling this with [0, MAX_UINT] regardless of their actual  
> > allocations?
> > 
> > IOASID can ensure that user can only free the PASIDs allocated to the user. but
> > it's true, kernel needs to loop all the PASIDs within the range provided by user. it
> > may take a long time. is there anything we can do? one thing may limit the range
> > provided by user?  
> 
> thought about it more, we have per-VM pasid quota (say 1000), so even if
> user passed down [0, MAX_UNIT], kernel will only loop the 1000 pasids at
> most. do you think we still need to do something on it?

How do you figure that?  vfio_iommu_type1_pasid_request() accepts the
user's min/max so long as (max > min) and passes that to
vfio_iommu_type1_pasid_free(), then to vfio_pasid_free_range()  which
loops as:

	ioasid_t pasid = min;
	for (; pasid <= max; pasid++)
		ioasid_free(pasid);

A user might only be able to allocate 1000 pasids, but apparently they
can ask to free all they want.

It's also not obvious to me that calling ioasid_free() is only allowing
the user to free their own passid.  Does it?  It would be a pretty
gaping hole if a user could free arbitrary pasids.  A r-b tree of
passids might help both for security and to bound spinning in a loop.
Thanks,

Alex


  reply	other threads:[~2020-07-08 19:55 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  8:55 [PATCH v3 00/14] vfio: expose virtual Shared Virtual Addressing to VMs Liu Yi L
2020-06-24  8:55 ` Liu Yi L
2020-06-24  8:55 ` [PATCH v3 01/14] vfio/type1: Refactor vfio_iommu_type1_ioctl() Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-07-02 21:21   ` Alex Williamson
2020-07-02 21:21     ` Alex Williamson
2020-07-03  3:46     ` Liu, Yi L
2020-07-03  3:46       ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 02/14] iommu: Report domain nesting info Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-26  7:47   ` Jean-Philippe Brucker
2020-06-26  7:47     ` Jean-Philippe Brucker
2020-06-26 16:04     ` Robin Murphy
2020-06-26 16:04       ` Robin Murphy
2020-06-27  6:53       ` Liu, Yi L
2020-06-27  6:53         ` Liu, Yi L
2020-06-30  1:20         ` Tian, Kevin
2020-06-30  1:20           ` Tian, Kevin
2020-06-27  6:14     ` Liu, Yi L
2020-06-27  6:14       ` Liu, Yi L
2020-06-29  9:24   ` Stefan Hajnoczi
2020-06-29  9:24     ` Stefan Hajnoczi
2020-06-29 12:23     ` Liu, Yi L
2020-06-29 12:23       ` Liu, Yi L
2020-06-30  2:00       ` Tian, Kevin
2020-06-30  2:00         ` Tian, Kevin
2020-06-30  3:45         ` Liu, Yi L
2020-06-30  3:45           ` Liu, Yi L
2020-07-03  9:59         ` Stefan Hajnoczi
2020-07-03  9:59           ` Stefan Hajnoczi
2020-07-02 17:54   ` Alex Williamson
2020-07-02 17:54     ` Alex Williamson
2020-07-03  3:53     ` Liu, Yi L
2020-07-03  3:53       ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 03/14] vfio/type1: Report iommu nesting info to userspace Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-07-02 18:38   ` Alex Williamson
2020-07-02 18:38     ` Alex Williamson
2020-07-03  6:05     ` Liu, Yi L
2020-07-03  6:05       ` Liu, Yi L
2020-07-03 13:03       ` Liu, Yi L
2020-07-03 13:03         ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 04/14] vfio: Add PASID allocation/free support Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-07-02 21:17   ` Alex Williamson
2020-07-02 21:17     ` Alex Williamson
2020-07-03  6:08     ` Liu, Yi L
2020-07-03  6:08       ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 05/14] iommu/vt-d: Support setting ioasid set to domain Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-24  8:55 ` [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free) Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-07-02 21:18   ` Alex Williamson
2020-07-02 21:18     ` Alex Williamson
2020-07-03  6:28     ` Liu, Yi L
2020-07-03  6:28       ` Liu, Yi L
2020-07-08  8:16       ` Liu, Yi L
2020-07-08  8:16         ` Liu, Yi L
2020-07-08 19:54         ` Alex Williamson [this message]
2020-07-08 19:54           ` Alex Williamson
2020-07-09  0:32           ` Liu, Yi L
2020-07-09  0:32             ` Liu, Yi L
2020-07-09  1:56             ` Tian, Kevin
2020-07-09  1:56               ` Tian, Kevin
2020-07-09  2:08               ` Liu, Yi L
2020-07-09  2:08                 ` Liu, Yi L
2020-07-09  2:18                 ` Tian, Kevin
2020-07-09  2:18                   ` Tian, Kevin
2020-07-09  2:26                   ` Liu, Yi L
2020-07-09  2:26                     ` Liu, Yi L
2020-07-09  7:16                     ` Liu, Yi L
2020-07-09  7:16                       ` Liu, Yi L
2020-07-09 14:27                       ` Alex Williamson
2020-07-09 14:27                         ` Alex Williamson
2020-07-09 18:05                         ` Jacob Pan
2020-07-09 18:05                           ` Jacob Pan
2020-07-10  5:39                         ` Liu, Yi L
2020-07-10  5:39                           ` Liu, Yi L
2020-07-10 12:55                           ` Alex Williamson
2020-07-10 12:55                             ` Alex Williamson
2020-07-10 13:03                             ` Liu, Yi L
2020-07-10 13:03                               ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 07/14] iommu: Pass domain to sva_unbind_gpasid() Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-24  8:55 ` [PATCH v3 08/14] iommu/vt-d: Check ownership for PASIDs from user-space Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-24  8:55 ` [PATCH v3 09/14] vfio/type1: Support binding guest page tables to PASID Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-07-02 21:19   ` Alex Williamson
2020-07-02 21:19     ` Alex Williamson
2020-07-03  6:46     ` Liu, Yi L
2020-07-03  6:46       ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 10/14] vfio/type1: Allow invalidating first-level/stage IOMMU cache Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-07-02 21:19   ` Alex Williamson
2020-07-02 21:19     ` Alex Williamson
2020-07-03  3:47     ` Liu, Yi L
2020-07-03  3:47       ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 11/14] vfio/type1: Add vSVA support for IOMMU-backed mdevs Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-24  8:55 ` [PATCH v3 12/14] vfio/pci: Expose PCIe PASID capability to guest Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-24  8:55 ` [PATCH v3 13/14] vfio: Document dual stage control Liu Yi L
2020-06-24  8:55   ` Liu Yi L
2020-06-29  9:21   ` Stefan Hajnoczi
2020-06-29  9:21     ` Stefan Hajnoczi
2020-06-29  9:24     ` Liu, Yi L
2020-06-29  9:24       ` Liu, Yi L
2020-06-24  8:55 ` [PATCH v3 14/14] iommu/vt-d: Support reporting nesting capability info Liu Yi L
2020-06-24  8:55   ` Liu Yi L

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=20200708135444.4eac48a4@x1.home \
    --to=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.l.liu@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.