| Message ID | 20191126141026.2858622-1-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [for-4.13] docs/xl: Document pci-assignable state | expand |
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>
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.
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
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
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
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.
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.
> -----Original Message----- > From: Ian Jackson <Ian.Jackson@citrix.com> > Sent: 26 November 2019 14:22 > To: George Dunlap <George.Dunlap@citrix.com> > Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Jan Beulich > <jbeulich@suse.com>; Paul Durrant <paul.durrant@citrix.com>; Juergen Gross > <jgross@suse.com> > Subject: Re: [PATCH for-4.13] docs/xl: Document pci-assignable state > > [resending to just Paul to fix email address problem] > > 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?) > Assigning any device carries a risk and can never considered to be secure in any general way. E.g. a device that exposes its config space in a writable fashion via an internal i2c bus that can be accessed via one of its BARs. Quarantining helps to the extent that, if a device is continuing to DMA than at least that doesn't hit dom0 whilst the FLR/SBR is attempted, but if even that's not effective then the device should probably remain in quarantine until it is power-cycled. Paul
> -----Original Message----- > From: Ian Jackson <ian.jackson@citrix.com> > Sent: 26 November 2019 15:06 > To: George Dunlap <george.dunlap@citrix.com>; xen- > devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Jan Beulich > <jbeulich@suse.com>; Durrant, Paul <pdurrant@amazon.com>; Juergen Gross > <jgross@suse.com> > Subject: Re: [PATCH for-4.13] docs/xl: Document pci-assignable state > > 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... > The text sounds fine in general but the 'as always' does rather imply 'hey, we never said PCI pass-through was safe, did we?' Paul
> -----Original Message----- > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Jan > Beulich > Sent: 26 November 2019 14:27 > To: Ian Jackson <ian.jackson@citrix.com> > Cc: Juergen Gross <jgross@suse.com>; xen-devel@lists.xenproject.org; Paul > Durrant <paul.durrant@citrix.com>; George Dunlap > <george.dunlap@citrix.com>; Wei Liu <wl@xen.org> > Subject: Re: [Xen-devel] [PATCH for-4.13] docs/xl: Document pci-assignable > state > > 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. Yes. I will hopefully find time to post the next version of that patch this week. Paul > > > (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
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>
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(-)