From: Igor Mammedov <imammedo@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ani Sinha <ani@anisinha.ca>, philmd@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH] hw/acpi/pcihp: validate bsel property of the bus before unplugging device
Date: Tue, 24 Aug 2021 10:56:14 +0200 [thread overview]
Message-ID: <20210824105614.2762541f@redhat.com> (raw)
In-Reply-To: <20210823190444-mutt-send-email-mst@kernel.org>
On Mon, 23 Aug 2021 19:06:47 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Sat, Aug 21, 2021 at 08:35:35PM +0530, Ani Sinha wrote:
> > Bsel property of the pci bus indicates whether the bus supports acpi hotplug.
> > We need to validate the presence of this property before performing any hotplug
> > related callback operations. Currently validation of the existence of this
> > property was absent from acpi_pcihp_device_unplug_cb() function but is present
> > in other hotplug/unplug callback functions. Hence, this change adds the missing
> > check for the above function.
> >
> > Signed-off-by: Ani Sinha <ani@anisinha.ca>
>
> I queued this but I have a general question:
I convinced myself that this patch is wrong, pls drop it.
> are all these errors logged with LOG_GUEST_ERROR?
> Because if not we have a security problem.
> I also note that bsel is an internal property,
> I am not sure we should be printing this to users,
> it might just confuse them.
>
> Same question for all the other places validating bsel.
Commit message misses reproducer/explanation about
how it could be triggered?
If it's actually reachable, from my point of view
putting checks all through out call chain is not robust
and it's easy to miss issues caused by invalid bsel.
Instead of putting check all over the code, I'd
check value on entry points (pci_read/pci_write)
if code there is broken.
>
> > ---
> > hw/acpi/pcihp.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> > index 0fd0c1d811..9982815a87 100644
> > --- a/hw/acpi/pcihp.c
> > +++ b/hw/acpi/pcihp.c
> > @@ -372,9 +372,15 @@ void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s,
> > DeviceState *dev, Error **errp)
> > {
> > PCIDevice *pdev = PCI_DEVICE(dev);
> > + int bsel = acpi_pcihp_get_bsel(pci_get_bus(pdev));
> > +
> > + trace_acpi_pci_unplug(PCI_SLOT(pdev->devfn), bsel);
> >
> > - trace_acpi_pci_unplug(PCI_SLOT(pdev->devfn),
> > - acpi_pcihp_get_bsel(pci_get_bus(pdev)));
> > + if (bsel < 0) {
> > + error_setg(errp, "Unsupported bus. Bus doesn't have property '"
> > + ACPI_PCIHP_PROP_BSEL "' set");
> > + return;
> > + }
1st:
Error here is useless. this path is triggered on guest
MMIO write and there is no consumer for error whatsoever.
If I recall correctly, in such cases we in PCIHP code we make
such access a silent NOP. And tracing is there for a us
to help figure out what's going on.
2nd:
if it got this far, it means a device on a bus with bsel
was found and we are completing cleanup. Error-ing out at
this point will leak acpi_index.
> >
> > /*
> > * clean up acpi-index so it could reused by another device
> > --
> > 2.25.1
>
next prev parent reply other threads:[~2021-08-24 9:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-21 15:05 [PATCH] hw/acpi/pcihp: validate bsel property of the bus before unplugging device Ani Sinha
2021-08-23 23:06 ` Michael S. Tsirkin
2021-08-24 5:24 ` Ani Sinha
2021-08-24 8:56 ` Igor Mammedov [this message]
2021-08-24 9:30 ` Ani Sinha
2021-08-24 10:37 ` Ani Sinha
2021-08-24 11:06 ` Ani Sinha
2021-08-24 11:35 ` Philippe Mathieu-Daudé
2021-08-24 13:33 ` Ani Sinha
2021-08-24 11:22 ` Igor Mammedov
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=20210824105614.2762541f@redhat.com \
--to=imammedo@redhat.com \
--cc=ani@anisinha.ca \
--cc=mst@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).