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

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Sep 23, 2019 at 02:05:58PM +0200, Jan Beulich wrote:
> 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.

What about this: HVM guest can already do all of this when qemu is
running in dom0. So, allowing those actions when qemu is running in
stubdomain should not introduce _additional_ risks.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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