[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

 - 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

I think there are other scenarios you are worried about and I'm
missing, could you please point them out?

Thanks, Roger.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.