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

["Michael S. Tsirkin" <mst@xxxxxxxxxx>]

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@xxxxxxxx>
> >>>
> >>> 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@xxxxxxxx>
> >>> Reviewed-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> >>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >> 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.

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

That one basically says don't pass through PFs if you want security :)
One has to wonder what's the point of XA-126 is then, it can only be
triggered with PFs.
I guess it'd apply to the theorectically possible "devices the entire
scope of whose functionality is known and has been reviewed for PCI
passthrough security and correctness". Do you know of such hardware
in real life?

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel