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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-04-01 at 10:20 +0100, Stefano Stabellini wrote:
> CC'ing the author of the patch and xen-devel.

Adding Andy C who I think knows about this stuff.

> 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@xxxxxxxx>
> > > 
> > > 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@xxxxxxxx>
> > > Reviewed-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > 
> > 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.

XSA-126 says:

        In the event that the platform surfaces aforementioned UR responses as
        Non-Maskable Interrupts, and either the OS is configured to treat NMIs
        as fatal or (e.g. via ACPI's APEI) the platform tells the OS to treat
        these errors as fatal, the host would crash, leading to a Denial of
        Service.

AIUI from the discussions on security@ (perhaps in the context of -120
rather than this) using ACPI APEI in this way is the norm. Andy?

> > Here's the description from pci express spec:
> > 
> > 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 host set Unsupported
> > Request Reporting Enable.
> > 
> > The right thing is for host kernel

I think part of the problem is that its not the host kernel acting as
"Completer" here, but rather the host firmware, which we do not control.
I think Andy can probably confirm or deny this.

Ian.


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