From: Isaku Yamahata <yamahata@valinux.co.jp>
To: Markus Armbruster <armbru@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Ignore pci unplug requests for unpluggable devices (CVE-2011-1751)
Date: Thu, 19 May 2011 20:52:48 +0900 [thread overview]
Message-ID: <20110519115248.GA28673@valinux.co.jp> (raw)
In-Reply-To: <m31uzv6ijd.fsf@blackfin.pond.sub.org>
On Thu, May 19, 2011 at 01:23:18PM +0200, Markus Armbruster wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
> > Hi,
> >
> > Markus Armbruster <armbru@redhat.com> writes:
> >
> >> Gerd Hoffmann <kraxel@redhat.com> writes:
> >>
> >>> This patch makes qemu ignore unplug requests from the guest for pci
> >>> devices which are tagged as non-hotpluggable. Trouble spot is the
> >>> piix4 chipset with the ISA bridge. Requests to unplug that one will
> >>> make it go away together with all ISA bus devices, which are not
> >>> prepared to be unplugged and thus don't cleanup, leaving active
> >>> qemu timers behind in free'ed memory.
> >>>
> >>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> >>> ---
> >>> hw/acpi_piix4.c | 4 +++-
> >>> 1 files changed, 3 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> >>> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> >>> index 96f5222..6c908ff 100644
> >>> --- a/hw/acpi_piix4.c
> >>> +++ b/hw/acpi_piix4.c
> >>> @@ -471,11 +471,13 @@ static void pciej_write(void *opaque, uint32_t addr, uint32_t val)
> >>> BusState *bus = opaque;
> >>> DeviceState *qdev, *next;
> >>> PCIDevice *dev;
> >>> + PCIDeviceInfo *info;
> >>> int slot = ffs(val) - 1;
> >>>
> >>> QLIST_FOREACH_SAFE(qdev,&bus->children, sibling, next) {
> >>> dev = DO_UPCAST(PCIDevice, qdev, qdev);
> >>> - if (PCI_SLOT(dev->devfn) == slot) {
> >>> + info = container_of(qdev->info, PCIDeviceInfo, qdev);
> >>> + if (PCI_SLOT(dev->devfn) == slot&& !info->no_hotplug) {
> >>> qdev_free(qdev);
> >>> }
> >>> }
> >>
> >> Looks good, but what about pcie_cap_slot_hotplug()?
> >
> > Dunno, didn't look at q35 yet. I'd expect the root bus isn't
> > hot-pluggable, so the guest wouldn't be able to rip out any essential
> > chipset devices. But having someone more familier with pcie + q35
> > double-check would be good ...
>
> I guess that would be Isaku Yamahata (cc'ed).
The root pci bus of q35 isn't hot pluggable. The pcie bus with
the hotplug capability means that the slot in the bus is always
hot pluggable. So pcie_cap_slot_hotplug() doesn't need to check
no_hotplug.
If some sort of check is wanted, the check should be done at
the device initialization, I think.
Populating a non-hotpluggable devince in hot pluggable slot doesn't make
sense.
thanks,
--
yamahata
prev parent reply other threads:[~2011-05-19 11:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 9:13 [Qemu-devel] [PULL] Fix CVE-2011-1751 Gerd Hoffmann
2011-05-19 9:13 ` [Qemu-devel] [PATCH] Ignore pci unplug requests for unpluggable devices (CVE-2011-1751) Gerd Hoffmann
2011-05-19 10:00 ` Markus Armbruster
2011-05-19 11:12 ` Gerd Hoffmann
2011-05-19 11:23 ` Markus Armbruster
2011-05-19 11:52 ` Isaku Yamahata [this message]
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=20110519115248.GA28673@valinux.co.jp \
--to=yamahata@valinux.co.jp \
--cc=armbru@redhat.com \
--cc=kraxel@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).