All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Cédric Le Goater" <clg@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Sriram Yagnaraman" <sriram.yagnaraman@est.tech>,
	"Jason Wang" <jasowang@redhat.com>,
	"Keith Busch" <kbusch@kernel.org>,
	"Klaus Jensen" <its@irrelevant.dk>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH v4 5/9] pcie_sriov: Validate NumVFs
Date: Wed, 14 Feb 2024 10:54:23 -0500	[thread overview]
Message-ID: <20240214105244-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <dbb8562b-6532-45af-a6fe-63bbf9b74a1d@daynix.com>

On Wed, Feb 14, 2024 at 11:49:52PM +0900, Akihiko Odaki wrote:
> On 2024/02/14 15:52, Michael S. Tsirkin wrote:
> > On Wed, Feb 14, 2024 at 02:13:43PM +0900, Akihiko Odaki wrote:
> > > The guest may write NumVFs greater than TotalVFs and that can lead
> > > to buffer overflow in VF implementations.
> > > 
> > > Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)")
> > > Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> > > ---
> > >   hw/pci/pcie_sriov.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
> > > index a1fe65f5d801..da209b7f47fd 100644
> > > --- a/hw/pci/pcie_sriov.c
> > > +++ b/hw/pci/pcie_sriov.c
> > > @@ -176,6 +176,9 @@ static void register_vfs(PCIDevice *dev)
> > >       assert(sriov_cap > 0);
> > >       num_vfs = pci_get_word(dev->config + sriov_cap + PCI_SRIOV_NUM_VF);
> > > +    if (num_vfs > pci_get_word(dev->config + sriov_cap + PCI_SRIOV_TOTAL_VF)) {
> > > +        return;
> > > +    }
> > 
> > 
> > yes but with your change PCI_SRIOV_NUM_VF no longer reflects the
> > number of registered VFs and that might lead to uninitialized
> > data read which is not better :(.
> > 
> > How about just forcing the PCI_SRIOV_NUM_VF register to be
> > below PCI_SRIOV_TOTAL_VF at all times?
> 
> PCI_SRIOV_NUM_VF is already divergent from the number of registered VFs. It
> may have a number greater than the current registered VFs before setting VF
> Enable.
> 
> The guest may also change PCI_SRIOV_NUM_VF while VF Enable is set; the
> behavior is undefined in such a case but we still accept such a write. A
> value written in such a case won't be reflected to the actual number of
> enabled VFs.

OK then let's add a comment near num_vfs explaining all this and saying
only to use this value. I also would prefer to have this if
just where we set num_vfs. And maybe after all do set num_vfs to
PCI_SRIOV_TOTAL_VF? Less of a chance of breaking something I feel...

-- 
MST



  reply	other threads:[~2024-02-14 15:54 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  5:13 [PATCH v4 0/9] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 1/9] hw/pci: Use -1 as a default value for rombar Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 2/9] hw/pci: Determine if rombar is explicitly enabled Akihiko Odaki
2024-02-14  6:49   ` Michael S. Tsirkin
2024-02-14  5:13 ` [PATCH v4 3/9] vfio: Avoid inspecting option QDict for rombar Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 4/9] hw/qdev: Remove opts member Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 5/9] pcie_sriov: Validate NumVFs Akihiko Odaki
2024-02-14  6:52   ` Michael S. Tsirkin
2024-02-14 14:49     ` Akihiko Odaki
2024-02-14 15:54       ` Michael S. Tsirkin [this message]
2024-02-14 16:22         ` Akihiko Odaki
2024-02-14  8:58   ` Michael Tokarev
2024-02-14 14:54     ` Akihiko Odaki
2024-02-14 15:53       ` Michael Tokarev
2024-02-14 15:55         ` Michael S. Tsirkin
2024-02-17 11:32           ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 6/9] pcie_sriov: Reuse SR-IOV VF device instances Akihiko Odaki
2024-02-14  7:54   ` Michael S. Tsirkin
2024-02-14 14:44     ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 7/9] pcie_sriov: Release VFs failed to realize Akihiko Odaki
2024-02-14  7:54   ` Michael S. Tsirkin
2024-02-14  7:58     ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 8/9] pcie_sriov: Do not reset NumVFs after unregistering VFs Akihiko Odaki
2024-02-14  6:53   ` Michael S. Tsirkin
2024-02-14 14:32     ` Akihiko Odaki
2024-02-14 15:51       ` Michael S. Tsirkin
2024-02-14 16:10         ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 9/9] hw/nvme: Refer to dev->exp.sriov_pf.num_vfs Akihiko Odaki
2024-02-14  7:07   ` Michael S. Tsirkin
2024-02-14 14:09     ` Akihiko Odaki
2024-02-14 15:46       ` Michael S. Tsirkin
2024-02-14 16:07         ` Akihiko Odaki
2024-02-14 16:34           ` Michael S. Tsirkin
2024-02-14 16:51             ` Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240214105244-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=akihiko.odaki@daynix.com \
    --cc=alex.williamson@redhat.com \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=its@irrelevant.dk \
    --cc=jasowang@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sriram.yagnaraman@est.tech \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.