[v1] docs/xl: Document pci-assignable state

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

Posted by George Dunlap 6 years, 2 months ago

Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
introduced PCI device "quarantine" behavior, but did not document how
the pci-assignable-add and -remove functions act in regard to this.
Rectify this.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Release justification: This brings documentation into line with the
actual code that will be released.

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Jan Beulich <jbeulich@suse.com>
CC: Paul Durrant <paul.durrant@citrix.com>
CC: Juergen Gross <jgross@suse.com>
---
 docs/man/xl.1.pod.in | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 2303b81e4f..372c229244 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -1589,10 +1589,12 @@ backend driver in domain 0 rather than a real driver.
 =item B<pci-assignable-add> I<BDF>
 
 Make the device at PCI Bus/Device/Function BDF assignable to guests.
-This will bind the device to the pciback driver.  If it is already
-bound to a driver, it will first be unbound, and the original driver
-stored so that it can be re-bound to the same driver later if desired.
-If the device is already bound, it will return success.
+This will bind the device to the pciback driver and assign it to the
+"quarantine domain".  If it is already bound to a driver, it will
+first be unbound, and the original driver stored so that it can be
+re-bound to the same driver later if desired.  If the device is
+already bound, it will assign it to the quarantine domain and return
+success.
 
 CAUTION: This will make the device unusable by Domain 0 until it is
 returned with pci-assignable-remove.  Care should therefore be taken
@@ -1602,11 +1604,18 @@ being used.
 
 =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.  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.
+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.
 
 =item B<pci-attach> I<domain-id> I<BDF>
 
-- 
2.24.0


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

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

Posted by Wei Liu 6 years, 2 months ago

On Tue, Nov 26, 2019 at 02:10:26PM +0000, George Dunlap wrote:
> Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> introduced PCI device "quarantine" behavior, but did not document how
> the pci-assignable-add and -remove functions act in regard to this.
> Rectify this.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

LGTM.

Acked-by: Wei Liu <wl@xen.org>

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

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

Posted by Ian Jackson 6 years, 2 months ago

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 ?

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

Ian.

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

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

Posted by George Dunlap 6 years, 2 months ago

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

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

Posted by Ian Jackson 6 years, 2 months ago

George Dunlap writes ("Re: [PATCH for-4.13] docs/xl: Document pci-assignable state"):
> 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."

SGTM.

I like "as always" which clearly signals that this is a more general
problem without requiring us to actually write that other
comprehensive document...

Ian.

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

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

Posted by Ian Jackson 6 years, 2 months ago

Ian Jackson writes ("Re: [PATCH for-4.13] docs/xl: Document pci-assignable state"):
> George Dunlap writes ("Re: [PATCH for-4.13] docs/xl: Document pci-assignable state"):
> > 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."
> 
> SGTM.
> 
> I like "as always" which clearly signals that this is a more general
> problem without requiring us to actually write that other
> comprehensive document...

Resending with Paul's new address.

Ian.

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

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

Posted by Jan Beulich 6 years, 2 months ago

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Posted by Jürgen Groß 6 years, 2 months ago

On 26.11.19 15:10, George Dunlap wrote:
> Changesets 319f9a0ba9 ("passthrough: quarantine PCI devices") and
> ba2ab00bbb ("IOMMU: default to always quarantining PCI devices")
> introduced PCI device "quarantine" behavior, but did not document how
> the pci-assignable-add and -remove functions act in regard to this.
> Rectify this.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

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