vfio/type1: check pfn valid before converting to struct page

  vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
e.g. for MMIO PFNs.

It's necessary to check if it's a valid pfn before calling pfn_to_page().

Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
---
 drivers/vfio/vfio_iommu_type1.c | 5 +++++
 1 file changed, 5 insertions(+)


base-commit: b3c98052d46948a8d65d2778c7f306ff38366aac
  

On Tue, May 16, 2023 at 05:30:07PM +0800, Yan Zhao wrote:
> vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
> e.g. for MMIO PFNs.
> 
> It's necessary to check if it's a valid pfn before calling pfn_to_page().
> 
> Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
> ---
>  drivers/vfio/vfio_iommu_type1.c | 5 +++++
>  1 file changed, 5 insertions(+)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason
  

On Tue, May 16, 2023, Yan Zhao wrote:
> vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
> e.g. for MMIO PFNs.
> 
> It's necessary to check if it's a valid pfn before calling pfn_to_page().
> 
> Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")

Might be worth adding a blurb to call out that this is _not_ ABI breakage.  Prior
to the buggy commit, KVMGT manually checked that the pfn pinned by vfio_pin_pages()
was pfn_valid(), and s390's driver(s) either blindly expected struct page memory,
e.g. did

        ret = page_array_pin(&pa, vdev);
        if (ret < 0) {
                page_array_unpin_free(&pa, vdev);
                return ret;
        }

        l = n;
        for (i = 0; i < pa.pa_nr; i++) {
                struct page *page = pfn_to_page(pa.pa_pfn[i]);
                void *from = kmap_local_page(page);

or in the case of its crypto driver, apparently was all kinds of confused about
virtual vs. physical, i.e. likely couldn't have worked with anything but "normal"
memory anyways.

AFAICT, those are the only in-tree users of vfio_pin_pages().
  

On Wed, May 17, 2023 at 08:19:04AM -0700, Sean Christopherson wrote:
> On Tue, May 16, 2023, Yan Zhao wrote:
> > vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
> > e.g. for MMIO PFNs.
> > 
> > It's necessary to check if it's a valid pfn before calling pfn_to_page().
> > 
> > Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
> 
> Might be worth adding a blurb to call out that this is _not_ ABI breakage.  Prior
Do you mean "_not_ ABI breakage" with
34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
or with this fix commit?

> to the buggy commit, KVMGT manually checked that the pfn pinned by vfio_pin_pages()
> was pfn_valid(), and s390's driver(s) either blindly expected struct page memory,
> e.g. did
> 
>         ret = page_array_pin(&pa, vdev);
>         if (ret < 0) {
>                 page_array_unpin_free(&pa, vdev);
>                 return ret;
>         }
> 
>         l = n;
>         for (i = 0; i < pa.pa_nr; i++) {
>                 struct page *page = pfn_to_page(pa.pa_pfn[i]);
>                 void *from = kmap_local_page(page);
> 
> or in the case of its crypto driver, apparently was all kinds of confused about
> virtual vs. physical, i.e. likely couldn't have worked with anything but "normal"
> memory anyways.
> 
> AFAICT, those are the only in-tree users of vfio_pin_pages().
Though there are no in-tree users currently expect vfio_pin_pages() to cover
MMIO ranges, with the
commit 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()"),
the IOVA ranges supported by vfio_pin_pages() is still reduced.

Previously, it's the callers(vendor drivers)' option to decide if they want to
support MMIO GFNs or not, while now only if there are other interfaces provided
by VFIO, the vendor drivers could not allow pinning of MMIO GFNs, i.e. no guest
P2P.
  

On Thu, May 18, 2023, Yan Zhao wrote:
> On Wed, May 17, 2023 at 08:19:04AM -0700, Sean Christopherson wrote:
> > On Tue, May 16, 2023, Yan Zhao wrote:
> > > vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
> > > e.g. for MMIO PFNs.
> > > 
> > > It's necessary to check if it's a valid pfn before calling pfn_to_page().
> > > 
> > > Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
> > 
> > Might be worth adding a blurb to call out that this is _not_ ABI breakage.  Prior
> Do you mean "_not_ ABI breakage" with
> 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
> or with this fix commit?

Mostly the former.  I brought it up because _if_ there was breakage in that commit,
then this fix would be "wrong" in the sense that it wouldn't undo any breakage, and
would likely make it harder to restore the previous behavior.
  

On Thu, May 18, 2023 at 11:07:09AM -0700, Sean Christopherson wrote:
> On Thu, May 18, 2023, Yan Zhao wrote:
> > On Wed, May 17, 2023 at 08:19:04AM -0700, Sean Christopherson wrote:
> > > On Tue, May 16, 2023, Yan Zhao wrote:
> > > > vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
> > > > e.g. for MMIO PFNs.
> > > > 
> > > > It's necessary to check if it's a valid pfn before calling pfn_to_page().
> > > > 
> > > > Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
> > > 
> > > Might be worth adding a blurb to call out that this is _not_ ABI breakage.  Prior
> > Do you mean "_not_ ABI breakage" with
> > 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
> > or with this fix commit?
> 
> Mostly the former.  I brought it up because _if_ there was breakage in that commit,
> then this fix would be "wrong" in the sense that it wouldn't undo any breakage, and
> would likely make it harder to restore the previous behavior.

Ok. Let me post v2 to describe the problem and background clearly.

Thanks!