From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFFI-0003dN-U3 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:47:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdFFG-0001QQ-4G for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:47:36 -0400 Received: from smtp.citrix.com ([66.165.176.89]:56261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFFG-0001Pl-0S for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:47:34 -0400 Message-ID: <551BBD38.60204@citrix.com> Date: Wed, 1 Apr 2015 10:41:12 +0100 From: Andrew Cooper MIME-Version: 1.0 References: <20150401103411-mutt-send-email-mst@redhat.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit 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: Stefano Stabellini , "Michael S. Tsirkin" Cc: xen-devel@lists.xensource.com, pmatouse@redhat.com, qemu-devel@nongnu.org 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. 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. > > >> In particular, there could be more reasons for devices >> to generate URs, for example, if they get a transaction >> during FLR. I don't think we ever tried to prevent this. > That cannot be triggered by guest behaviour. What cannot be triggered by guest behaviour? Many devices have secondary access into config space via a BAR, which allows a guest driver full and unmediated control of everything. Under Xen, we have covered this with XSA-124 which basically says that for such devices, all bets are off. ~Andrew