linux-kernel - Re: [PATCH] vfio/type1: check pfn valid before converting to struct page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 May 2023 08:52:12 +0800
From:   Yan Zhao <yan.y.zhao@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
CC:     <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <alex.williamson@...hat.com>, <kevin.tian@...el.com>,
        <jgg@...dia.com>
Subject: Re: [PATCH] vfio/type1: check pfn valid before converting to struct
 page

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.