Re: [Xen-devel] [PATCH for-4.13] docs/xl: Document pci-assignable state

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.11.2019 15:14, Ian Jackson wrote:
> George Dunlap writes ("[PATCH for-4.13] docs/xl: Document pci-assignable 
> state"):
>>  =item B<pci-assignable-remove> [I<-r>] I<BDF>
> ...
>> +Make the device at PCI Bus/Device/Function BDF not assignable to
>> +guests.  This will at least unbind the device from pciback, and
>> +re-assign it from the "quarantine domain" back to domain 0.  If the -r
>> +option is specified, it will also attempt to re-bind the device to its
>> +original driver, making it usable by Domain 0 again.  If the device is
>> +not bound to pciback, it will return success.
>> +
>> +Note that this functionality will work even for devices which were not
>> +made assignable by B<pci-assignable-add>.  This can be used to allow
>> +dom0 to access devices which were automatically quarantined by Xen
>> +after domain destruction as a result of Xen's B<iommu=quarantine>
>> +command-line default.
> 
> What are the security implications of doing this if the device might
> still be doing DMA or something ?

Devices get reset in between, so well behaving ones should not
still be doing DMA at that point. Misbehaving ones would better
not be assigned (back and forth) anyway. But a recent patch of
Paul's suggests that people still wish to do so, on the
assumption that such DMA will drain sufficiently quickly.

> (For that matter, presumably there are security implications of
> assigning the same device in sequence to different guests?)

Right.

Jan

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