public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Xu Yandong <xuyandong2@huawei.com>
Cc: <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<zhang.zhanghailiang@huawei.com>, <wangxinxin.wang@huawei.com>,
	Kirti Wankhede <kwankhede@nvidia.com>
Subject: Re: [PATCH] vfio iommu type1: no need to check task->mm if task has been destroyed
Date: Thu, 19 Apr 2018 10:19:26 -0600	[thread overview]
Message-ID: <20180419101926.5700f8a9@w520.home> (raw)
In-Reply-To: <20180418105545.13488-1-xuyandong2@huawei.com>

[cc +Kirti]

On Wed, 18 Apr 2018 18:55:45 +0800
Xu Yandong <xuyandong2@huawei.com> wrote:

> The task structure in vfio_dma struct used to identify the same
> task who map it or other task who shares same adress space is
> allowed to unmap. But if the task who map it has exited, mm of
> the task has been set to null, we should unmap the vfio dma directly.
> 
> Signed-off-by: Xu Yandong <xuyandong2@huawei.com>
> ---
> Hi all,
> When I unplug a vcpu from a VM lanched with a VFIO hostdev device,
> I found that the *vfio_dma* mapped by this vcpu task could not be unmaped
> in the future, so I send this patch to unmap vfio_dma directly if the
> task who mapped it has exited. 
> 
> Howerver this patch may introduce a new security risk because any task can 
> unmap the *vfio_dma* if the mapper task has exited.  

Well that's unexpected, but adding some debugging code I can clearly
see that the map and unmap ioctls are typically called by the various
processor threads, which all share the same mm_struct (so accounting is
correct regardless of which CPU does the unmap).  I don't think the fix
below is correct though, it's not for a security risk, but for
accounting issue and correctness issues.  The pages are mapped and
accounted against the users locked memory limits, if we simply bail
out, both the IOMMU mappings and the limit accounting are wrong.
Perhaps rather than referencing the calling task_struct in the vfio_dma
on mapping, we should traverse to the highest parent task sharing the
same mm_struct.  Kirti, any thoughts since this code originated for
mdev support?  Thanks,

Alex
 
> ---
>  drivers/vfio/vfio_iommu_type1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5c212bf..601a353 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -947,7 +947,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
>  		 * Task with same address space who mapped this iova range is
>  		 * allowed to unmap the iova range.
>  		 */
> -		if (dma->task->mm != current->mm)
> +		if (dma->task->mm && (dma->task->mm != current->mm))
>  			break;
>  
>  		if (!RB_EMPTY_ROOT(&dma->pfn_list)) {

  reply	other threads:[~2018-04-19 16:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18 10:55 [PATCH] vfio iommu type1: no need to check task->mm if task has been destroyed Xu Yandong
2018-04-19 16:19 ` Alex Williamson [this message]
2018-04-19 19:54   ` Alex Williamson
2018-04-20 11:52     ` xuyandong

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=20180419101926.5700f8a9@w520.home \
    --to=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wangxinxin.wang@huawei.com \
    --cc=xuyandong2@huawei.com \
    --cc=zhang.zhanghailiang@huawei.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