qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com,
	Jan Beulich <jbeulich@suse.com>,
	Stefano.Stabellini@eu.citrix.com
Subject: [Qemu-devel] [PULL 03/11] xen/MSI-X: limit error messages
Date: Tue, 2 Jun 2015 16:40:20 +0100	[thread overview]
Message-ID: <1433259628-4611-3-git-send-email-stefano.stabellini@eu.citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1506021633010.19838@kaball.uk.xensource.com>

From: Jan Beulich <jbeulich@suse.com>

Limit error messages resulting from bad guest behavior to avoid allowing
the guest to cause the control domain's disk to fill.

The first message in pci_msix_write() can simply be deleted, as this
is indeed bad guest behavior, but such out of bounds writes don't
really need to be logged.

The second one is more problematic, as there guest behavior may only
appear to be wrong: For one, the old logic didn't take the mask-all bit
into account. And then this shouldn't depend on host device state (i.e.
the host may have masked the entry without the guest having done so).
Plus these writes shouldn't be dropped even when an entry is unmasked.
Instead, if they can't be made take effect right away, they should take
effect on the next unmasking or enabling operation - the specification
explicitly describes such caching behavior. Until we can validly drop
the message (implementing such caching/latching behavior), issue the
message just once per MSI-X table entry.

Note that the log message in pci_msix_read() similar to the one being
removed here is not an issue: "addr" being of unsigned type, and the
maximum size of the MSI-X table being 32k, entry_nr simply can't be
negative and hence the conditonal guarding issuing of the message will
never be true.

This is XSA-130.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/xen/xen_pt.h     |    1 +
 hw/xen/xen_pt_msi.c |   12 +++++++-----
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 52ceb85..8c9b6c2 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -175,6 +175,7 @@ typedef struct XenPTMSIXEntry {
     uint32_t data;
     uint32_t vector_ctrl;
     bool updated; /* indicate whether MSI ADDR or DATA is updated */
+    bool warned;  /* avoid issuing (bogus) warning more than once */
 } XenPTMSIXEntry;
 typedef struct XenPTMSIX {
     uint32_t ctrl_offset;
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 9ed9321..68db623 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -434,11 +434,10 @@ static void pci_msix_write(void *opaque, hwaddr addr,
     XenPCIPassthroughState *s = opaque;
     XenPTMSIX *msix = s->msix;
     XenPTMSIXEntry *entry;
-    int entry_nr, offset;
+    unsigned int entry_nr, offset;
 
     entry_nr = addr / PCI_MSIX_ENTRY_SIZE;
-    if (entry_nr < 0 || entry_nr >= msix->total_entries) {
-        XEN_PT_ERR(&s->dev, "asked MSI-X entry '%i' invalid!\n", entry_nr);
+    if (entry_nr >= msix->total_entries) {
         return;
     }
     entry = &msix->msix_entry[entry_nr];
@@ -460,8 +459,11 @@ static void pci_msix_write(void *opaque, hwaddr addr,
             + PCI_MSIX_ENTRY_VECTOR_CTRL;
 
         if (msix->enabled && !(*vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
-            XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
-                       " already enabled.\n", entry_nr);
+            if (!entry->warned) {
+                entry->warned = true;
+                XEN_PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is"
+                           " already enabled.\n", entry_nr);
+            }
             return;
         }
 
-- 
1.7.10.4

  parent reply	other threads:[~2015-06-02 15:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-02 15:39 [Qemu-devel] [PULL 0/11] Xen PCI Passthrough security fixes Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 01/11] xen: properly gate host writes of modified PCI CFG contents Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 02/11] xen: don't allow guest to control MSI mask register Stefano Stabellini
2015-06-02 15:40 ` Stefano Stabellini [this message]
2015-06-02 15:40 ` [Qemu-devel] [PULL 04/11] xen/MSI: don't open-code pass-through of enable bit modifications Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 05/11] xen/pt: consolidate PM capability emu_mask Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 06/11] xen/pt: correctly handle PM status bit Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 07/11] xen/pt: split out calculation of throughable mask in PCI config space handling Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 08/11] xen/pt: mark all PCIe capability bits read-only Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 09/11] xen/pt: mark reserved bits in PCI config space fields Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 10/11] xen/pt: add a few PCI config space field descriptions Stefano Stabellini
2015-06-02 15:40 ` [Qemu-devel] [PULL 11/11] xen/pt: unknown PCI config space fields should be read-only Stefano Stabellini
2015-06-02 16:43 ` [Qemu-devel] [PULL 0/11] Xen PCI Passthrough security fixes Peter Maydell

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=1433259628-4611-3-git-send-email-stefano.stabellini@eu.citrix.com \
    --to=stefano.stabellini@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=xen-devel@lists.xensource.com \
    /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).