Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 13, 2015 at 09:17:04AM +0100, Jan Beulich wrote:
> >>> On 01.04.15 at 11:59, <mst@redhat.com> wrote:
> > On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote:
> >> On 01/04/15 10:20, Stefano Stabellini wrote:
> >> > CC'ing the author of the patch and xen-devel.
> >> > FYI I think that Jan is going to be on vacation for a couple of weeks.
> >> >
> >> > On Wed, 1 Apr 2015, Michael S. Tsirkin wrote:
> >> >> On Tue, Mar 31, 2015 at 03:18:03PM +0100, Stefano Stabellini wrote:
> >> >>> From: Jan Beulich <jbeulich@suse.com>
> >> >>>
> >> >>> Otherwise the guest can abuse that control to cause e.g. PCIe
> >> >>> Unsupported Request responses (by disabling memory and/or I/O decoding
> >> >>> and subsequently causing [CPU side] accesses to the respective address
> >> >>> ranges), which (depending on system configuration) may be fatal to the
> >> >>> host.
> >> >>>
> >> >>> This is CVE-2015-2756 / XSA-126.
> >> >>>
> >> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> >>> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> >>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >> >> The patch description seems somewhat incorrect to me.
> >> >> UR should not be fatal to the system, and it's not platform
> >> >> specific.
> >> > I think that people have been able to repro this, but I'll let Jan
> >> > comment on it.
> >> 
> >> Depending on how the BIOS sets up AER (if even available), a UR can very
> >> easily be fatal to the system.
> >> 
> >> If firmware first mode is set, Xen (or indeed Linux) can't fix a
> >> problematic setup.  Experimentally, doing so can cause infinite loops in
> >> certain vendors SMM handlers.
> > 
> > I think it can, just disable UR reporting, this is up to OS.  This is
> > what the PCI spec says - you have snipped the relevant part out from the
> > mail you are replying to.
> 
> As already said by Andrew, the OS must not do such when the
> system is in APEI firmware first mode.
> 
> Jan


Yes Linux can't fix firmware 1st mode, but
PCI express spec says what firmware should do in this case:

IMPLEMENTATION NOTE Software UR Reporting Compatibility with 1.0a Devices

        With 1.0a device Functions, 96 if the Unsupported Request Reporting Enable bit is set, the Function
        when operating as a Completer will send an uncorrectable error Message (if enabled) when a UR
        error is detected. On platforms where an uncorrectable error Message is handled as a System Error,
        this will break PC-compatible Configuration Space probing, so software/firmware on such
        platforms may need to avoid setting the Unsupported Request Reporting Enable bit.
        With device Functions implementing Role-Based Error Reporting, setting the Unsupported Request
        Reporting Enable bit will not interfere with PC-compatible Configuration Space probing, assuming
        that the severity for UR is left at its default of non-fatal. However, setting the Unsupported Request
        Reporting Enable bit will enable the Function to report UR errors detected with posted Requests,
        helping avoid this case for potential silent data corruption.
        On platforms where robust error handling and PC-compatible Configuration Space probing is
        required, it is suggested that software or firmware have the Unsupported Request Reporting Enable
        bit Set for Role-Based Error Reporting Functions, but clear for 1.0a Functions. Software or
        firmware can distinguish the two classes of Functions by examining the Role-Based Error Reporting
        bit in the Device Capabilities register.


What I think you have is a very old 1.0a system, and you set Unsupported
Request Reporting Enable.

Can you confirm?

If you have access to the system in question, I can provide
a test script to detect this.

You will have other problems if your firmware doesn't follow the spec. So how
about either

- Don't use firmware 1st mode with pci express
  (Seems no reason to do firmware 1st for PCIE, architecture is completely
   standard. I saw mentions of using combined/parallel mode, using AER for some
   devices but not others, but I don't know how this is supposed to be enabled.
   Any idea?)

or

- ask your vendor to update firmware if it doesn't do the right thing

-- 
MST