All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xiantao.zhang@intel.com
Subject: Re: [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets
Date: Mon, 28 Apr 2014 10:34:05 +0100	[thread overview]
Message-ID: <535E208D.2080805@citrix.com> (raw)
In-Reply-To: <535E2702020000780000CACC@nat28.tlf.novell.com>


[-- Attachment #1.1: Type: text/plain, Size: 2268 bytes --]

On 28/04/14 09:01, Jan Beulich wrote:
> Add two more PCI IDs to the set that has been taken care of with a
> different workaround long before XSA-59, and (for constency with the
> newer workarounds) log a message here too.
>
> Also move the function wide comment to the cases it applies to; this
> should really have been done by d061d200 ("VT-d: suppress UR signaling
> for server chipsets").
>
> This is CVE-2013-3495 / XSA-59.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

As before, this would probably be better being a conditional message.

~Andrew

>
> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -379,12 +379,6 @@ void me_wifi_quirk(struct domain *domain
>      }
>  }
>  
> -/*
> - * Mask reporting Intel VT-d faults to IOH core logic:
> - *   - Some platform escalates VT-d faults to platform errors 
> - *   - This can cause system failure upon non-fatal VT-d faults
> - *   - Potential security issue if malicious guest trigger VT-d faults
> - */
>  void pci_vtd_quirk(const struct pci_dev *pdev)
>  {
>      int seg = pdev->seg;
> @@ -402,10 +396,20 @@ void pci_vtd_quirk(const struct pci_dev 
>  
>      switch ( pci_conf_read16(seg, bus, dev, func, PCI_DEVICE_ID) )
>      {
> +    /*
> +     * Mask reporting Intel VT-d faults to IOH core logic:
> +     *   - Some platform escalates VT-d faults to platform errors.
> +     *   - This can cause system failure upon non-fatal VT-d faults.
> +     *   - Potential security issue if malicious guest trigger VT-d faults.
> +     */
> +    case 0x0e28: /* Xeon-E5v2 (IvyBridge) */
>      case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */
> +    case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
>      case 0x3c28: /* Sandybridge */
>          val = pci_conf_read32(seg, bus, dev, func, 0x1AC);
>          pci_conf_write32(seg, bus, dev, func, 0x1AC, val | (1 << 31));
> +        printk(XENLOG_INFO "Masked VT-d error signaling on %04x:%02x:%02x.%u\n",
> +               seg, bus, dev, func);
>          break;
>  
>      /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 3044 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2014-04-28  9:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28  7:54 [PATCH 0/2] VT-d: further XSA-59 workaround adjustments Jan Beulich
2014-04-28  8:01 ` [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot Jan Beulich
2014-04-28  9:30   ` Andrew Cooper
2014-04-28  9:55     ` Jan Beulich
2014-04-28 10:01       ` Andrew Cooper
2014-05-20  0:46   ` Zhang, Xiantao
2014-04-28  8:01 ` [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets Jan Beulich
2014-04-28  9:34   ` Andrew Cooper [this message]
2014-04-28  9:56     ` Jan Beulich
2014-04-28  9:57       ` Andrew Cooper
2014-05-20  0:47   ` Zhang, Xiantao
2014-05-08  8:07 ` Ping: [PATCH 0/2] VT-d: further XSA-59 workaround adjustments Jan Beulich
2014-05-16  9:30   ` Ping II: " Jan Beulich
     [not found] <A9667DDFB95DB7438FA9D7D576C3D87E0AACE649@SHSMSX104.ccr.corp.intel.com>
2014-05-20 13:39 ` [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets Zhang, Yang Z

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=535E208D.2080805@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=donald.d.dugger@intel.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiantao.zhang@intel.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 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.