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

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

On Wed, Apr 01, 2015 at 10:50:45AM +0100, Ian Campbell wrote:
> 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@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.
> 
> 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?

The implementation note at the bottom explains when this
happens I think: it's when you are using a 1.0a function
(which is pretty old - 1.1 went out 10 years ago)
and enable UR reporting in the AER register.

It sounds quite reasonable to detect such hardware and disable UR
reporting, even though APEI tells you AER is supported.

> 
> > > 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.

No, the Completer is the assigned device.
Host firmware configures whether uncorrectable error Message generates
NMIs, but it's not the one that configures Unsupported Request Reporting
Enable - host OS does this.

-- 
MST