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

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3451 bytes --]

On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> On 20.09.2019 18:02, Marek Marczykowski-Górecki  wrote:
> > On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> >> On 14.09.2019 17:37, Marek Marczykowski-Górecki  wrote:
> >>> Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> >>> bypassing pciback. While pciback is still used to access config space
> >>> from within stubdomain, it refuse to write to
> >>> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE/PCI_COMMAND_INTX_DISABLE
> >>> in non-permissive mode. Which is the right thing to do for PV domain
> >>> (the main use case for pciback), as PV domain should use XEN_PCI_OP_*
> >>> commands for that. Unfortunately those commands are not good for
> >>> stubdomain use, as they configure MSI in dom0's kernel too, which should
> >>> not happen for HVM domain.
> >>
> >> Why the "for HVM domain" here? I.e. why would this be correct for
> >> a PV domain? Besides my dislike for such a bypass (imo all of the
> >> handling should go through pciback, or none of it) I continue to
> >> wonder whether the problem can't be addressed by a pciback change.
> >> And even if not, I'd still wonder whether the request shouldn't go
> >> through pciback, to retain proper layering. Ultimately it may be
> >> better to have even the map/unmap go through pciback (it's at
> >> least an apparent violation of the original physdev-op model that
> >> these two are XSM_DM_PRIV).
> > 
> > Technically it should be possible to move this part to pciback, and in
> > fact this is what I've considered in the first version of this series.
> > But Roger points out on each version[1] of this series that pciback is
> > meant to serve *PV* domains, where a PCI passthrough is a completely
> > different different beast. In fact, I even consider that using pcifront
> > in a Linux stubdomain as a proxy for qemu there may be a bad idea (one
> > needs to be careful to avoid stubdomain kernel fighting with qemu about
> > device state).
> 
> Well, not using pciback _at all_ in this case would be another option.
> What I dislike is the furthering of hybrid-ness.

Ah, I see. This may be a good idea, if this type of PCI passthrough is
going to stay. If we're going away from qemu towards other options
mentioned in previous email, I'd say such a rework is too much work for a
time limited usefulness.
> 
> > 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?

-- 
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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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