Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.09.2019 12:47, Marek Marczykowski-Górecki  wrote:
> On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
>> On 20.09.2019 18:02, Marek Marczykowski-Górecki  wrote:
>>> Anyway, if you all agree that pciback should be the way to go, I can go
>>> that route too. In practice, it would be a flag (set by the toolstack?)
>>> allowing writes to appropriate config space registers directly (with
>>> appropriate checks, as in this patch).
>>
>> I'm afraid I don't agree: How would allowing writes to more config space
>> registers by a stubdom be safe?
> 
> Exactly the same as in this patch: pciback would perform the same
> validation (prohibit enabling MSI together with INTx etc).
> 
> BTW what are the risks (besides DoS) of allowing full config space
> access, assuming VT-d with interrupt remapping present? This sounds
> similar to risks of malicious device connected to some domU, right? Can
> such device (or a domain controlling such device) break out to Xen or
> dom0? Can it steal data from other domains?

There shouldn't be, but this would need proving. The direction of
proof then should be the other way around (and I realize it may be
[close to] impossible): Widening what guests (including stub
domains) are allowed to do should be proven to add no additional
risks. It shouldn't be (by example, as I imply from your question)
that an actual issue needs to be pointed out.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel