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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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.

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