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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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. 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.

Jan


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