[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201007173911.GX5177@ziepe.ca>
Date: Wed, 7 Oct 2020 14:39:11 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: DRI Development <dri-devel@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org,
linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, linux-media@...r.kernel.org,
linux-s390@...r.kernel.org,
Daniel Vetter <daniel.vetter@...el.com>,
Kees Cook <keescook@...omium.org>,
Dan Williams <dan.j.williams@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
John Hubbard <jhubbard@...dia.com>,
Jérôme Glisse <jglisse@...hat.com>,
Jan Kara <jack@...e.cz>,
Alex Williamson <alex.williamson@...hat.com>,
Cornelia Huck <cohuck@...hat.com>
Subject: Re: [PATCH 13/13] vfio/type1: Mark follow_pfn as unsafe
On Wed, Oct 07, 2020 at 06:44:26PM +0200, Daniel Vetter wrote:
> The code seems to stuff these pfns into iommu pts (or something like
> that, I didn't follow), but there's no mmu_notifier to ensure that
> access is synchronized with pte updates.
>
> Hence mark these as unsafe. This means that with
> CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
>
> Real fix is to wire up an mmu_notifier ... somehow. Probably means any
> invalidate is a fatal fault for this vfio device, but then this
> shouldn't ever happen if userspace is reasonable.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@...el.com>
> Cc: Jason Gunthorpe <jgg@...pe.ca>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Dan Williams <dan.j.williams@...el.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: John Hubbard <jhubbard@...dia.com>
> Cc: Jérôme Glisse <jglisse@...hat.com>
> Cc: Jan Kara <jack@...e.cz>
> Cc: Dan Williams <dan.j.williams@...el.com>
> Cc: linux-mm@...ck.org
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-samsung-soc@...r.kernel.org
> Cc: linux-media@...r.kernel.org
> Cc: Alex Williamson <alex.williamson@...hat.com>
> Cc: Cornelia Huck <cohuck@...hat.com>
> Cc: kvm@...r.kernel.org
> ---
> drivers/vfio/vfio_iommu_type1.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 5fbf0c1f7433..a4d53f3d0a35 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -421,7 +421,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma, struct mm_struct *mm,
> {
> int ret;
>
> - ret = follow_pfn(vma, vaddr, pfn);
> + ret = unsafe_follow_pfn(vma, vaddr, pfn);
> if (ret) {
> bool unlocked = false;
>
> @@ -435,7 +435,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma, struct mm_struct *mm,
> if (ret)
> return ret;
>
> - ret = follow_pfn(vma, vaddr, pfn);
> + ret = unsafe_follow_pfn(vma, vaddr, pfn);
> }
This is actually being commonly used, so it needs fixing.
When I talked to Alex about this last we had worked out a patch series
that adds a test on vm_ops that the vma came from vfio in the first
place. The VMA's created by VFIO are 'safe' as the PTEs are never changed.
Jason
Powered by blists - more mailing lists