linux-kernel - Re: [PATCH v5 05/14] vfio/mdev: idxd: add basic mdev registration and helper functions

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]

Message-ID: <20210216213119.GI4247@nvidia.com>
Date:   Tue, 16 Feb 2021 17:31:19 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Dan Williams <dan.j.williams@...el.com>
CC:     Dave Jiang <dave.jiang@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        <kwankhede@...dia.com>, Thomas Gleixner <tglx@...utronix.de>,
        Vinod Koul <vkoul@...nel.org>,
        "Dey, Megha" <megha.dey@...el.com>,
        Jacob jun Pan <jacob.jun.pan@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>, Yi L Liu <yi.l.liu@...el.com>,
        Baolu Lu <baolu.lu@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        Sanjay K Kumar <sanjay.k.kumar@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>, <eric.auger@...hat.com>,
        Parav Pandit <parav@...lanox.com>, <netanelg@...lanox.com>,
        <shahafs@...lanox.com>, Paolo Bonzini <pbonzini@...hat.com>,
        <dmaengine@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KVM list <kvm@...r.kernel.org>
Subject: Re: [PATCH v5 05/14] vfio/mdev: idxd: add basic mdev registration
 and helper functions

On Tue, Feb 16, 2021 at 12:39:56PM -0800, Dan Williams wrote:
> > >> +    /*
> > >> +     * Check and see if the guest wants to map to the limited or unlimited portal.
> > >> +     * The driver will allow mapping to unlimited portal only if the the wq is a
> > >> +     * dedicated wq. Otherwise, it goes to limited.
> > >> +     */
> > >> +    virt_portal = ((offset >> PAGE_SHIFT) & 0x3) == 1;
> > >> +    phys_portal = IDXD_PORTAL_LIMITED;
> > >> +    if (virt_portal == IDXD_PORTAL_UNLIMITED && wq_dedicated(wq))
> > >> +            phys_portal = IDXD_PORTAL_UNLIMITED;
> > >> +
> > >> +    /* We always map IMS portals to the guest */
> > >> +    pgoff = (base + idxd_get_wq_portal_full_offset(wq->id, phys_portal,
> > >> +                                                   IDXD_IRQ_IMS)) >> PAGE_SHIFT;
> > >> +    dev_dbg(dev, "mmap %lx %lx %lx %lx\n", vma->vm_start, pgoff, req_size,
> > >> +            pgprot_val(pg_prot));
> > >> +    vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > >> +    vma->vm_private_data = mdev;
> > > What ensures the mdev pointer is valid strictly longer than the VMA?
> > > This needs refcounting.
> >
> > Going to take a kref at open and then put_device at close. Does that
> > sound reasonable or should I be calling get_device() in mmap() and then
> > register a notifier for when vma is released?
> 
> Where does this enabling ever look at vm_private_data again?

So long as a PCI BAR page is mapped into a VMA the pci driver cannot
be removed. Things must either wait until the fd (or at least all
VMAs) are closed, or zap the VMAs before allowing the device driver to
be removed.

There should be some logic in this whole thing where the pci_driver
destroys the mdevs which destroy the vfio's which wait for all the fds
to be closed.

There is enough going on in vfio_device_fops_release() that this might
happen already, Dave needs to investigate and confirm the whole thing
works as expected.

Presumably there is no security issue with sharing these portal pages
because I don't see a vma ops involved here to track when pages are
freed up (ie the vm_private_data is dead code cargo-cult'd from
someplace else)

But this is all sufficiently tricky, and Intel has already had
security bugs in their drivers here, that someone needs to audit it
closely before it gets posted again.

Jason