linux-kernel - Re: [PATCH 1/5] iov: Update virtfn_max_buses to validate offset and stride

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: <20151029195010.GB19083@localhost>
Date:	Thu, 29 Oct 2015 14:50:10 -0500
From:	Bjorn Helgaas <helgaas@...nel.org>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	Alexander Duyck <aduyck@...antis.com>, bhelgaas@...gle.com,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] iov: Update virtfn_max_buses to validate offset and
 stride

On Wed, Oct 28, 2015 at 02:46:50PM -0700, Alexander Duyck wrote:
> On 10/28/2015 11:43 AM, Bjorn Helgaas wrote:
> >On Wed, Oct 28, 2015 at 11:32:16AM -0500, Bjorn Helgaas wrote:

> >Here's my new proposal:
> >
> >   static int compute_max_vf_buses(struct pci_dev *dev)
> >   {
> >           struct pci_sriov *iov = dev->sriov;
> >           int nr_virtfn, busnr, rc = 0;
> >
> >           for (nr_virtfn = iov->total_VFs; nr_virtfn; nr_virtfn--) {
> >                   pci_iov_set_numvfs(dev, nr_virtfn);
> >                   if (!iov->offset || (nr_virtfn > 1 && !iov->stride)) {
> >                           rc = -EIO;
> >                           goto out;
> >                   }
> >
> >                   busnr = pci_iov_virtfn_bus(dev, nr_virtfn - 1);
> >                   if (busnr > iov->max_VF_buses)
> >                           iov->max_VF_buses = busnr;
> >           }
> >
> >   out:
> >           pci_iov_set_numvfs(dev, 0);
> >           return rc;
> >   }
> >
> 
> This looks good to me.  In theory you could save yourself a pair of
> MMIO reads at the end of the loop by just writing numvfs without the
> offset and stride read, but this should work.

True.  It's called once per device at boot-time, so it's not a hot path,
and I think it's worth two unnecessary MMIO reads to make it easier to
analyze: there's exactly one place that updates PCI_SRIOV_NUM_VF, and that
place always updates our caches of PCI_SRIOV_VF_OFFSET and
PCI_SRIOV_VF_STRIDE.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/