Re: [Xen-devel] vpci: deferral of register write until p2m changes are done

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Nov 29, 2018 at 03:41:07AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 11:25, <roger.pau@xxxxxxxxxx> wrote:
> > On Thu, Nov 29, 2018 at 02:25:02AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.18 at 18:48, <roger.pau@xxxxxxxxxx> wrote:
> >> > On Wed, Nov 28, 2018 at 10:04:33AM -0700, Jan Beulich wrote:
> >> >> >>> On 28.11.18 at 17:54, <roger.pau@xxxxxxxxxx> wrote:
> >> >> > On Wed, Nov 28, 2018 at 09:22:16AM -0700, Jan Beulich wrote:
> >> >> >> >>> On 28.11.18 at 16:41, <roger.pau@xxxxxxxxxx> wrote:
> >> >> >> > My plan is that DomUs won't be allowed to toggle the memory 
> >> >> >> > decoding
> >> >> >> > bit, and it's going to be always enabled, like it's currently done 
> >> >> >> > for
> >> >> >> > pci-passthrough in QEMU. Toggling the memory decoding bit in a 
> >> >> >> > DomU is
> >> >> >> > going to trigger a change to the p2m (map or unmap) but the command
> >> >> >> > register will always have the memory decoding bit enabled.
> >> >> >> 
> >> >> >> But this isn't entirely correct, even if we've got away with this
> >> >> >> so far. But we're mostly considering well-behaved guests and
> >> >> >> devices. What if one actually triggers bus activity in parallel to
> >> >> >> a BAR change?
> >> >> > 
> >> >> > Well, that's likely to not work properly in any case with or without
> >> >> > disabling the memory decoding bit?
> >> >> 
> >> >> Of course not.
> >> >> 
> >> >> > But I don't see how that's going to affect Xen stability (or what the
> >> >> > domain is attempting to achieve with it).
> >> >> 
> >> >> "I don't see how ..." != "That's not going to ...". And in case my
> >> >> prior way of wording it was ambiguous: We very much need to
> >> >> think about malicious guests (once any of this is to be extended
> >> >> to DomU-s). Hence a goal of "I want to crash Xen" needs to be
> >> >> taken into consideration.
> >> > 
> >> > Right, so Xen might what to disable memory decoding for DomUs also.
> >> > 
> >> > But that's orthogonal to whether we agree that the write to the
> >> > command register can happen before the p2m modifications, both in the
> >> > map and the unmap case. I think so, but I would like to be sure you
> >> > agree before I code this.
> >> 
> >> Thing is, as said before, I'm not sure. I can be convinced by, well,
> >> convincing arguments (which a proof that nothing bad can happen
> >> would be, but anything less likely wouldn't).
> > 
> > Hm, OK, please bear with me because I'm afraid I will need some help
> > in order to provide such argument.
> > 
> > We agree that the end result is going to be the same, ie: a p2m change
> > and a write to the device command register. Then the issue is the
> > order in which to perform those, and whether that order will have a
> > security impact.
> > 
> > We also agree that in the unmap case it's best to first disable memory
> > decoding and then perform the p2m unmap. So the only remaining
> > problematic case is the map action.
> > 
> > I guess the only vector of a possible attack could be other vCPUs in a
> > SMP guest, that could poke at either the device registers or the p2m
> > after the memory decoding bit has been set and while the map operation
> > is taking place:
> > 
> >  - Writing to the BARs MMIO while performing the p2m map and with the
> >    memory decoding bit is enabled can result in missing writes not
> >    reaching the device, because the p2m entries are not yet setup.
> >    This can also be triggered by the guest when the BARs are
> >    completely mapped by performing incorrect writes.
> 
> Not sure what "incorrect writes" you mean here. Ones to other GFNs
> are not targeted at the device in question anyway. But yes, P2M
> mappings not in place _should_ not have any bad effects. My issue
> is with the "should not" here, which I'd like to be "cannot".
> 
> >  - Attempting to program a DMA transaction to the device MMIO BAR
> >    regions will result in IOMMU page faults, the same can be achieved by
> >    attempting to perform DMA transactions to unpopulated memory
> >    regions.
> > 
> > I think there are other scenarios you are worried about and I'm
> > missing, could you please point them out?
> 
> That's the point: I can't point out other scenarios, but I also can't
> convince myself that there are none. What I'm concerned about
> from a more abstract pov are any actions by the guest which might
> ultimately lead to master or target aborts (or alike), which may in
> turn cause #SERR to be signaled.

I cannot see how interactions with a device with half-mapped BARs
could trigger aborts that cannot be triggered when the device has
fully mapped BARs. Ie: if there's indeed a way to trigger such aborts
it would also be possible to do so with fully mapped BARs.

> Yet then again we all know that
> PCI pass-through is not perfectly secure despite all claims (or
> should I say wishes), so maybe all of this is really tolerable.

Well, we already know there are devices that expose backdoors to the
PCI config space in a BAR, so it's mostly a question of whether you
trust the devices you are passing through.

Thanks, Roger.

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