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

["Jan Beulich" <JBeulich@suse.com>]

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