From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhZYQ-0005oY-05 for qemu-devel@nongnu.org; Mon, 13 Apr 2015 04:17:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhZYM-0005JF-MH for qemu-devel@nongnu.org; Mon, 13 Apr 2015 04:17:13 -0400 Received: from mail.emea.novell.com ([130.57.118.101]:33932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhZYM-0005Iz-D9 for qemu-devel@nongnu.org; Mon, 13 Apr 2015 04:17:10 -0400 Message-Id: <552B97A00200007800071558@mail.emea.novell.com> Date: Mon, 13 Apr 2015 09:17:04 +0100 From: "Jan Beulich" References: <20150401103411-mutt-send-email-mst@redhat.com> <551BBD38.60204@citrix.com> <20150401115032-mutt-send-email-mst@redhat.com> In-Reply-To: <20150401115032-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Andrew Cooper , xen-devel@lists.xensource.com, pmatouse@redhat.com, qemu-devel@nongnu.org, Stefano Stabellini >>> On 01.04.15 at 11:59, 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 >> >>> >> >>> 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 >> >>> Reviewed-by: Stefano Stabellini >> >>> Acked-by: Ian Campbell >> >> 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. >>=20 >> Depending on how the BIOS sets up AER (if even available), a UR can = very >> easily be fatal to the system. >>=20 >> 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. >=20 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register Date: Mon, 13 Apr 2015 09:17:04 +0100 Message-ID: <552B97A00200007800071558@mail.emea.novell.com> References: <20150401103411-mutt-send-email-mst@redhat.com> <551BBD38.60204@citrix.com> <20150401115032-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20150401115032-mutt-send-email-mst@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: "Michael S. Tsirkin" Cc: Andrew Cooper , xen-devel@lists.xensource.com, pmatouse@redhat.com, qemu-devel@nongnu.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org >>> On 01.04.15 at 11:59, 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 >> >>> >> >>> 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 >> >>> Reviewed-by: Stefano Stabellini >> >>> Acked-by: Ian Campbell >> >> 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. >>=20 >> Depending on how the BIOS sets up AER (if even available), a UR can = very >> easily be fatal to the system. >>=20 >> 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. >=20 > 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