On 11/26/19 2:14 PM, 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 ?
Then the device might scribble over any memory dom0 has access to.
Function-level reset will theoretically stop this, but fundamentally we
have to consider it unreliable in the general case. Same thing for
assigning to a different guest.
I kind of feel like the discussion of the security risks inherent in pci
passthrough belong in a separate document, but perhaps a brief mention
here would be helpful. Perhaps the following?
"As always, this should only be done if you trust the guest, or are
confident that the particular device you're re-assigning to dom0 will
cancel all in-flight DMA on FLR."
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
