>>> On 01.04.15 at 11:59, <m...@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 <jbeul...@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 <jbeul...@suse.com> >> >>> Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com> >> >>> Acked-by: Ian Campbell <ian.campb...@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
