Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 16/12/2019 08:24, Jürgen Groß wrote: > On 16.12.19 06:58, Tian, Kevin wrote: >>> From: Jürgen Groß >>> Sent: Friday, December 13, 2019 11:36 PM >>> >>> On 13.12.19 15:45, Jan Beulich wrote: On 13.12.2019 15:24, Jürgen Groß wrote: > On 13.12.19 15:11, Jan Beulich wrote: >> On 13.12.2019 14:46, Jürgen Groß wrote: >>> On 13.12.19 14:38, Jan Beulich wrote: On 13.12.2019 14:31, Jürgen Groß wrote: > Maybe I have misunderstood the current state, but I thought that it > would just silently hide quirky devices without imposing a security > risk. We would not learn which devices are quirky, but OTOH I doubt > we'd get many reports about those in case your patch goes in. We don't want or need such reports, that's not the point. The security risk comes from the quirkiness of the devices - admins may wrongly think all is well and expose quirky devices to not sufficiently trusted guests. (I say this fully realizing that exposing devices to untrusted guests is almost always a certain level of risk.) >>> >>> Do we _know_ those devices are problematic from security standpoint? >>> Normally the IOMMU should do the isolation just fine. If it doesn't >>> then its not the quirky device which is problematic, but the IOMMU. >>> >>> I thought the problem was that the quirky devices would not stop all >>> (read) DMA even when being unassigned from the guest resulting in >>> fatal IOMMU faults. The dummy page should stop those faults to >>> happen >>> resulting in a more stable system. >> >> IOMMU faults by themselves are not impacting stability (they will >> add processing overhead, yes). The problem, according to Paul's >> description, is that the occurrence of at least some forms of IOMMU >> faults (not present ones as it seems, as opposed to permission >> violation ones) is fatal to certain systems. Irrespective of the >> sink page used after de-assignment a guest can arrange for IOMMU >> faults to occur even while it still has the device assigned. Hence >> it is important for the admin to know that their system (not the >> the particular device) behaves in this undesirable way. > > So how does the admin learn this? Its not as if your patch would result > in a system crash or hang all the time, right? This would be the case > only if there either is a malicious (on purpose or due to a bug) guest > which gets the device assigned, or if there happens to be a pending DMA > operation when the device gets unassigned. I didn't claim the change would cover all cases. All I am claiming is that it increases the chances of admins becoming aware of reasons not to pass through devices to certain guests. >>> >>> So combined with your answer this means to me: >>> >>> With your patch (or the original one reverted) a DoS will occur either >>> due to a malicious guest or in case a DMA is still pending. As a result >>> the admin will no longer pass this device to any untrusted guest. >>> >>> With the current 4.13-staging a DoS will occur only due to a malicious >>> guest. The admin will then no longer pass this device to any untrusted >>> guest. >>> >>> So right now without any untrusted guest no DoS, while possibly DoS with >>> your patch. How is that better? >>> >> >> I'd suggest separating run-time DoS from original quarantine purpose >> of this patch. >> >> For quarantine, I'm with Jan that giving admin the chance of knowing >> whether quarantine is required is important. Say an admin just gets >> a sample device from a new vendor and needs to decide whether his >> employer should put such device in their production system. It's >> essential to have a default configuration which can warn on any >> possible violation of the expectations on a good assignable device. >> Then the admin can look at Xen user guide to find out what the warning >> information means and then does whatever required (usually means >> more scrutinization than the warning itself) to figure out whether >> identified problems are safe (e.g. by enabling quarantine) or are >> real indicators of bogus implementation (then should not use it). >> Having quarantine default on means that every admin should remember >> that Xen already enables some band-aids on benign warnings so he >> should explicitly turn off those options to do evaluation which, to me >> is not realistic. > > This implies the admin is aware of the necessity to do that testing. > And for the tests to be conclusive he probably needs to do more than > just a basic "does it work" test, as the pending DMA might occur in > some cases only. And that is basically my problem with Jan's default: > an admin not doing enough testing (or non at all) will end up with a > DoS situation in production, while an admin knowing that he needs to > test properly is probably more aware of
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 16.12.19 06:58, Tian, Kevin wrote: From: Jürgen Groß Sent: Friday, December 13, 2019 11:36 PM On 13.12.19 15:45, Jan Beulich wrote: On 13.12.2019 15:24, Jürgen Groß wrote: On 13.12.19 15:11, Jan Beulich wrote: On 13.12.2019 14:46, Jürgen Groß wrote: On 13.12.19 14:38, Jan Beulich wrote: On 13.12.2019 14:31, Jürgen Groß wrote: Maybe I have misunderstood the current state, but I thought that it would just silently hide quirky devices without imposing a security risk. We would not learn which devices are quirky, but OTOH I doubt we'd get many reports about those in case your patch goes in. We don't want or need such reports, that's not the point. The security risk comes from the quirkiness of the devices - admins may wrongly think all is well and expose quirky devices to not sufficiently trusted guests. (I say this fully realizing that exposing devices to untrusted guests is almost always a certain level of risk.) Do we _know_ those devices are problematic from security standpoint? Normally the IOMMU should do the isolation just fine. If it doesn't then its not the quirky device which is problematic, but the IOMMU. I thought the problem was that the quirky devices would not stop all (read) DMA even when being unassigned from the guest resulting in fatal IOMMU faults. The dummy page should stop those faults to happen resulting in a more stable system. IOMMU faults by themselves are not impacting stability (they will add processing overhead, yes). The problem, according to Paul's description, is that the occurrence of at least some forms of IOMMU faults (not present ones as it seems, as opposed to permission violation ones) is fatal to certain systems. Irrespective of the sink page used after de-assignment a guest can arrange for IOMMU faults to occur even while it still has the device assigned. Hence it is important for the admin to know that their system (not the the particular device) behaves in this undesirable way. So how does the admin learn this? Its not as if your patch would result in a system crash or hang all the time, right? This would be the case only if there either is a malicious (on purpose or due to a bug) guest which gets the device assigned, or if there happens to be a pending DMA operation when the device gets unassigned. I didn't claim the change would cover all cases. All I am claiming is that it increases the chances of admins becoming aware of reasons not to pass through devices to certain guests. So combined with your answer this means to me: With your patch (or the original one reverted) a DoS will occur either due to a malicious guest or in case a DMA is still pending. As a result the admin will no longer pass this device to any untrusted guest. With the current 4.13-staging a DoS will occur only due to a malicious guest. The admin will then no longer pass this device to any untrusted guest. So right now without any untrusted guest no DoS, while possibly DoS with your patch. How is that better? I'd suggest separating run-time DoS from original quarantine purpose of this patch. For quarantine, I'm with Jan that giving admin the chance of knowing whether quarantine is required is important. Say an admin just gets a sample device from a new vendor and needs to decide whether his employer should put such device in their production system. It's essential to have a default configuration which can warn on any possible violation of the expectations on a good assignable device. Then the admin can look at Xen user guide to find out what the warning information means and then does whatever required (usually means more scrutinization than the warning itself) to figure out whether identified problems are safe (e.g. by enabling quarantine) or are real indicators of bogus implementation (then should not use it). Having quarantine default on means that every admin should remember that Xen already enables some band-aids on benign warnings so he should explicitly turn off those options to do evaluation which, to me is not realistic. This implies the admin is aware of the necessity to do that testing. And for the tests to be conclusive he probably needs to do more than just a basic "does it work" test, as the pending DMA might occur in some cases only. And that is basically my problem with Jan's default: an admin not doing enough testing (or non at all) will end up with a DoS situation in production, while an admin knowing that he needs to test properly is probably more aware of the needed command line option for evaluation of the device's security relevance. Its a complex problem and I think the decision for the default should not be rushed. So I think it is best to discuss it on xen-devel and leave the patch out of the initial 4.13 release (this patch is the last pending one for 4.13 now). After a decision is made the patch can easily by backported to 4.13 in case it is regarded to be important. Juergen ___ Xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
> From: Tian, Kevin > Sent: Monday, December 16, 2019 1:58 PM > > > From: Jürgen Groß > > Sent: Friday, December 13, 2019 11:36 PM > > > > On 13.12.19 15:45, Jan Beulich wrote: > > > On 13.12.2019 15:24, Jürgen Groß wrote: > > >> On 13.12.19 15:11, Jan Beulich wrote: > > >>> On 13.12.2019 14:46, Jürgen Groß wrote: > > On 13.12.19 14:38, Jan Beulich wrote: > > > On 13.12.2019 14:31, Jürgen Groß wrote: > > >> Maybe I have misunderstood the current state, but I thought that it > > >> would just silently hide quirky devices without imposing a security > > >> risk. We would not learn which devices are quirky, but OTOH I > doubt > > >> we'd get many reports about those in case your patch goes in. > > > > > > We don't want or need such reports, that's not the point. The > > > security risk comes from the quirkiness of the devices - admins > > > may wrongly think all is well and expose quirky devices to not > > > sufficiently trusted guests. (I say this fully realizing that > > > exposing devices to untrusted guests is almost always a certain > > > level of risk.) > > > > Do we _know_ those devices are problematic from security > standpoint? > > Normally the IOMMU should do the isolation just fine. If it doesn't > > then its not the quirky device which is problematic, but the IOMMU. > > > > I thought the problem was that the quirky devices would not stop all > > (read) DMA even when being unassigned from the guest resulting in > > fatal IOMMU faults. The dummy page should stop those faults to > > happen > > resulting in a more stable system. > > >>> > > >>> IOMMU faults by themselves are not impacting stability (they will > > >>> add processing overhead, yes). The problem, according to Paul's > > >>> description, is that the occurrence of at least some forms of IOMMU > > >>> faults (not present ones as it seems, as opposed to permission > > >>> violation ones) is fatal to certain systems. Irrespective of the > > >>> sink page used after de-assignment a guest can arrange for IOMMU > > >>> faults to occur even while it still has the device assigned. Hence > > >>> it is important for the admin to know that their system (not the > > >>> the particular device) behaves in this undesirable way. > > >> > > >> So how does the admin learn this? Its not as if your patch would result > > >> in a system crash or hang all the time, right? This would be the case > > >> only if there either is a malicious (on purpose or due to a bug) guest > > >> which gets the device assigned, or if there happens to be a pending DMA > > >> operation when the device gets unassigned. > > > > > > I didn't claim the change would cover all cases. All I am claiming > > > is that it increases the chances of admins becoming aware of reasons > > > not to pass through devices to certain guests. > > > > So combined with your answer this means to me: > > > > With your patch (or the original one reverted) a DoS will occur either > > due to a malicious guest or in case a DMA is still pending. As a result > > the admin will no longer pass this device to any untrusted guest. > > > > With the current 4.13-staging a DoS will occur only due to a malicious > > guest. The admin will then no longer pass this device to any untrusted > > guest. > > > > So right now without any untrusted guest no DoS, while possibly DoS with > > your patch. How is that better? > > > > I'd suggest separating run-time DoS from original quarantine purpose > of this patch. > > For quarantine, I'm with Jan that giving admin the chance of knowing > whether quarantine is required is important. Say an admin just gets > a sample device from a new vendor and needs to decide whether his > employer should put such device in their production system. It's > essential to have a default configuration which can warn on any > possible violation of the expectations on a good assignable device. > Then the admin can look at Xen user guide to find out what the warning > information means and then does whatever required (usually means > more scrutinization than the warning itself) to figure out whether > identified problems are safe (e.g. by enabling quarantine) or are > real indicators of bogus implementation (then should not use it). > Having quarantine default on means that every admin should remember > that Xen already enables some band-aids on benign warnings so he > should explicitly turn off those options to do evaluation which, to me > is not realistic. > > On the other hand, although a sink page can help mitigate run-time DoS, > how to handle it should be an admin policy. If DoS is caused by > malicious guest, it makes more sense to warn the admin and then switch > to sink page after meeting a DoS detection condition (e.g. number of > faults within a timing window exceeds a threshold). Lots of such warnings > from multiple VMs may imply a massive attack then the admin may adopt > more comprehensive
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
> From: Roger Pau Monné
> Sent: Friday, December 13, 2019 10:13 PM
>
> On Fri, Dec 13, 2019 at 01:53:29PM +0100, Jan Beulich wrote:
> > Containing still in flight DMA was introduced to work around certain
> > devices / systems hanging hard upon hitting an IOMMU fault. Passing
> > through (such) devices (on such systems) is inherently insecure (as
> > guests could easily arrange for IOMMU faults to occur). Defaulting to
> > a mode where admins may not even become aware of issues with devices
> can
> > be considered undesirable. Therefore convert this mode of operation to
> > an optional one, not one enabled by default.
> >
> > This involves resurrecting code commit ea38867831da ("x86 / iommu: set
> > up a scratch page in the quarantine domain") did remove, in a slightly
> > extended and abstracted fashion. Here, instead of reintroducing a pretty
> > pointless use of "goto" in domain_context_unmap(), and instead of making
> > the function (at least temporarily) inconsistent, take the opportunity
> > and replace the other similarly pointless "goto" as well.
> >
> > In order to key the re-instated bypasses off of there (not) being a root
> > page table this further requires moving the allocate_domain_resources()
> > invocation from reassign_device() to amd_iommu_setup_domain_device()
> (or
> > else reassign_device() would allocate a root page table anyway); this is
> > benign to the second caller of the latter function.
> >
> > Signed-off-by: Jan Beulich
>
> Reviewed-by: Roger Pau Monné
>
> I'm however not sure if the default quarantine mode should be the
> basic or the full one.
>
> At the end of day the full one does prevent hard hangs on specific
> systems, but a guest with a device behind such bogus IOMMU can
> trivially trigger those anyway.
It's a bogus device behind a good IOMMU. If IOMMU is bogus, we
should not pass through devices behind it.
>
> > ---
> > As far as 4.13 is concerned, I guess if we can't come to an agreement
> > here, the only other option is to revert ea38867831da from the branch,
> > for having been committed prematurely (I'm not so much worried about
> the
> > master branch, where we have ample time until 4.14). What I surely want
> > to see us avoid is a back and forth in behavior of released versions.
> > (Note that 4.12.2 is similarly blocked on a decision either way here.)
> >
> > I'm happy to take better suggestions to replace "full".
>
> I was going to comment on v1, but I really have no better alternative.
>
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -30,13 +30,17 @@ bool_t __initdata iommu_enable = 1;
> > bool_t __read_mostly iommu_enabled;
> > bool_t __read_mostly force_iommu;
> > bool_t __read_mostly iommu_verbose;
> > -bool __read_mostly iommu_quarantine = true;
> > bool_t __read_mostly iommu_igfx = 1;
> > bool_t __read_mostly iommu_snoop = 1;
> > bool_t __read_mostly iommu_qinval = 1;
> > bool_t __read_mostly iommu_intremap = 1;
> > bool_t __read_mostly iommu_crash_disable;
> >
> > +#define IOMMU_quarantine_none 0
> > +#define IOMMU_quarantine_basic 1
> > +#define IOMMU_quarantine_full 2
> > +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic;
>
> I wonder whether the default should be to use the sink page. Not using
> it can lead to a hard hang on certain hardware according to the
> description. OTOH if such devices are actually passed through, the
> guest itself can trigger such page faults and hence freeze the system.
>
> Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
> From: Jürgen Groß > Sent: Friday, December 13, 2019 11:36 PM > > On 13.12.19 15:45, Jan Beulich wrote: > > On 13.12.2019 15:24, Jürgen Groß wrote: > >> On 13.12.19 15:11, Jan Beulich wrote: > >>> On 13.12.2019 14:46, Jürgen Groß wrote: > On 13.12.19 14:38, Jan Beulich wrote: > > On 13.12.2019 14:31, Jürgen Groß wrote: > >> Maybe I have misunderstood the current state, but I thought that it > >> would just silently hide quirky devices without imposing a security > >> risk. We would not learn which devices are quirky, but OTOH I doubt > >> we'd get many reports about those in case your patch goes in. > > > > We don't want or need such reports, that's not the point. The > > security risk comes from the quirkiness of the devices - admins > > may wrongly think all is well and expose quirky devices to not > > sufficiently trusted guests. (I say this fully realizing that > > exposing devices to untrusted guests is almost always a certain > > level of risk.) > > Do we _know_ those devices are problematic from security standpoint? > Normally the IOMMU should do the isolation just fine. If it doesn't > then its not the quirky device which is problematic, but the IOMMU. > > I thought the problem was that the quirky devices would not stop all > (read) DMA even when being unassigned from the guest resulting in > fatal IOMMU faults. The dummy page should stop those faults to > happen > resulting in a more stable system. > >>> > >>> IOMMU faults by themselves are not impacting stability (they will > >>> add processing overhead, yes). The problem, according to Paul's > >>> description, is that the occurrence of at least some forms of IOMMU > >>> faults (not present ones as it seems, as opposed to permission > >>> violation ones) is fatal to certain systems. Irrespective of the > >>> sink page used after de-assignment a guest can arrange for IOMMU > >>> faults to occur even while it still has the device assigned. Hence > >>> it is important for the admin to know that their system (not the > >>> the particular device) behaves in this undesirable way. > >> > >> So how does the admin learn this? Its not as if your patch would result > >> in a system crash or hang all the time, right? This would be the case > >> only if there either is a malicious (on purpose or due to a bug) guest > >> which gets the device assigned, or if there happens to be a pending DMA > >> operation when the device gets unassigned. > > > > I didn't claim the change would cover all cases. All I am claiming > > is that it increases the chances of admins becoming aware of reasons > > not to pass through devices to certain guests. > > So combined with your answer this means to me: > > With your patch (or the original one reverted) a DoS will occur either > due to a malicious guest or in case a DMA is still pending. As a result > the admin will no longer pass this device to any untrusted guest. > > With the current 4.13-staging a DoS will occur only due to a malicious > guest. The admin will then no longer pass this device to any untrusted > guest. > > So right now without any untrusted guest no DoS, while possibly DoS with > your patch. How is that better? > I'd suggest separating run-time DoS from original quarantine purpose of this patch. For quarantine, I'm with Jan that giving admin the chance of knowing whether quarantine is required is important. Say an admin just gets a sample device from a new vendor and needs to decide whether his employer should put such device in their production system. It's essential to have a default configuration which can warn on any possible violation of the expectations on a good assignable device. Then the admin can look at Xen user guide to find out what the warning information means and then does whatever required (usually means more scrutinization than the warning itself) to figure out whether identified problems are safe (e.g. by enabling quarantine) or are real indicators of bogus implementation (then should not use it). Having quarantine default on means that every admin should remember that Xen already enables some band-aids on benign warnings so he should explicitly turn off those options to do evaluation which, to me is not realistic. On the other hand, although a sink page can help mitigate run-time DoS, how to handle it should be an admin policy. If DoS is caused by malicious guest, it makes more sense to warn the admin and then switch to sink page after meeting a DoS detection condition (e.g. number of faults within a timing window exceeds a threshold). Lots of such warnings from multiple VMs may imply a massive attack then the admin may adopt more comprehensive analysis or defensive means. Then it's also possible that DoS is caused by a vulnerability within the guest. In such case, the guest may want to contain the DoS attack itself through a virtual IOMMU. Then Xen needs to know the fault and
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 16:35, Jürgen Groß wrote: > On 13.12.19 15:45, Jan Beulich wrote: >> On 13.12.2019 15:24, Jürgen Groß wrote: >>> On 13.12.19 15:11, Jan Beulich wrote: On 13.12.2019 14:46, Jürgen Groß wrote: > On 13.12.19 14:38, Jan Beulich wrote: >> On 13.12.2019 14:31, Jürgen Groß wrote: >>> Maybe I have misunderstood the current state, but I thought that it >>> would just silently hide quirky devices without imposing a security >>> risk. We would not learn which devices are quirky, but OTOH I doubt >>> we'd get many reports about those in case your patch goes in. >> >> We don't want or need such reports, that's not the point. The >> security risk comes from the quirkiness of the devices - admins >> may wrongly think all is well and expose quirky devices to not >> sufficiently trusted guests. (I say this fully realizing that >> exposing devices to untrusted guests is almost always a certain >> level of risk.) > > Do we _know_ those devices are problematic from security standpoint? > Normally the IOMMU should do the isolation just fine. If it doesn't > then its not the quirky device which is problematic, but the IOMMU. > > I thought the problem was that the quirky devices would not stop all > (read) DMA even when being unassigned from the guest resulting in > fatal IOMMU faults. The dummy page should stop those faults to happen > resulting in a more stable system. IOMMU faults by themselves are not impacting stability (they will add processing overhead, yes). The problem, according to Paul's description, is that the occurrence of at least some forms of IOMMU faults (not present ones as it seems, as opposed to permission violation ones) is fatal to certain systems. Irrespective of the sink page used after de-assignment a guest can arrange for IOMMU faults to occur even while it still has the device assigned. Hence it is important for the admin to know that their system (not the the particular device) behaves in this undesirable way. >>> >>> So how does the admin learn this? Its not as if your patch would result >>> in a system crash or hang all the time, right? This would be the case >>> only if there either is a malicious (on purpose or due to a bug) guest >>> which gets the device assigned, or if there happens to be a pending DMA >>> operation when the device gets unassigned. >> >> I didn't claim the change would cover all cases. All I am claiming >> is that it increases the chances of admins becoming aware of reasons >> not to pass through devices to certain guests. > > So combined with your answer this means to me: > > With your patch (or the original one reverted) a DoS will occur either > due to a malicious guest or in case a DMA is still pending. As a result > the admin will no longer pass this device to any untrusted guest. > > With the current 4.13-staging a DoS will occur only due to a malicious > guest. The admin will then no longer pass this device to any untrusted > guest. > > So right now without any untrusted guest no DoS, while possibly DoS with > your patch. How is that better? I'm afraid this way we can debate endlessly, because it's not like there's a clear winner here. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.19 15:45, Jan Beulich wrote: On 13.12.2019 15:24, Jürgen Groß wrote: On 13.12.19 15:11, Jan Beulich wrote: On 13.12.2019 14:46, Jürgen Groß wrote: On 13.12.19 14:38, Jan Beulich wrote: On 13.12.2019 14:31, Jürgen Groß wrote: Maybe I have misunderstood the current state, but I thought that it would just silently hide quirky devices without imposing a security risk. We would not learn which devices are quirky, but OTOH I doubt we'd get many reports about those in case your patch goes in. We don't want or need such reports, that's not the point. The security risk comes from the quirkiness of the devices - admins may wrongly think all is well and expose quirky devices to not sufficiently trusted guests. (I say this fully realizing that exposing devices to untrusted guests is almost always a certain level of risk.) Do we _know_ those devices are problematic from security standpoint? Normally the IOMMU should do the isolation just fine. If it doesn't then its not the quirky device which is problematic, but the IOMMU. I thought the problem was that the quirky devices would not stop all (read) DMA even when being unassigned from the guest resulting in fatal IOMMU faults. The dummy page should stop those faults to happen resulting in a more stable system. IOMMU faults by themselves are not impacting stability (they will add processing overhead, yes). The problem, according to Paul's description, is that the occurrence of at least some forms of IOMMU faults (not present ones as it seems, as opposed to permission violation ones) is fatal to certain systems. Irrespective of the sink page used after de-assignment a guest can arrange for IOMMU faults to occur even while it still has the device assigned. Hence it is important for the admin to know that their system (not the the particular device) behaves in this undesirable way. So how does the admin learn this? Its not as if your patch would result in a system crash or hang all the time, right? This would be the case only if there either is a malicious (on purpose or due to a bug) guest which gets the device assigned, or if there happens to be a pending DMA operation when the device gets unassigned. I didn't claim the change would cover all cases. All I am claiming is that it increases the chances of admins becoming aware of reasons not to pass through devices to certain guests. So combined with your answer this means to me: With your patch (or the original one reverted) a DoS will occur either due to a malicious guest or in case a DMA is still pending. As a result the admin will no longer pass this device to any untrusted guest. With the current 4.13-staging a DoS will occur only due to a malicious guest. The admin will then no longer pass this device to any untrusted guest. So right now without any untrusted guest no DoS, while possibly DoS with your patch. How is that better? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 15:24, Jürgen Groß wrote: > On 13.12.19 15:11, Jan Beulich wrote: >> On 13.12.2019 14:46, Jürgen Groß wrote: >>> On 13.12.19 14:38, Jan Beulich wrote: On 13.12.2019 14:31, Jürgen Groß wrote: > Maybe I have misunderstood the current state, but I thought that it > would just silently hide quirky devices without imposing a security > risk. We would not learn which devices are quirky, but OTOH I doubt > we'd get many reports about those in case your patch goes in. We don't want or need such reports, that's not the point. The security risk comes from the quirkiness of the devices - admins may wrongly think all is well and expose quirky devices to not sufficiently trusted guests. (I say this fully realizing that exposing devices to untrusted guests is almost always a certain level of risk.) >>> >>> Do we _know_ those devices are problematic from security standpoint? >>> Normally the IOMMU should do the isolation just fine. If it doesn't >>> then its not the quirky device which is problematic, but the IOMMU. >>> >>> I thought the problem was that the quirky devices would not stop all >>> (read) DMA even when being unassigned from the guest resulting in >>> fatal IOMMU faults. The dummy page should stop those faults to happen >>> resulting in a more stable system. >> >> IOMMU faults by themselves are not impacting stability (they will >> add processing overhead, yes). The problem, according to Paul's >> description, is that the occurrence of at least some forms of IOMMU >> faults (not present ones as it seems, as opposed to permission >> violation ones) is fatal to certain systems. Irrespective of the >> sink page used after de-assignment a guest can arrange for IOMMU >> faults to occur even while it still has the device assigned. Hence >> it is important for the admin to know that their system (not the >> the particular device) behaves in this undesirable way. > > So how does the admin learn this? Its not as if your patch would result > in a system crash or hang all the time, right? This would be the case > only if there either is a malicious (on purpose or due to a bug) guest > which gets the device assigned, or if there happens to be a pending DMA > operation when the device gets unassigned. I didn't claim the change would cover all cases. All I am claiming is that it increases the chances of admins becoming aware of reasons not to pass through devices to certain guests. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 15:29, Jürgen Groß wrote: > On 13.12.19 15:23, Jan Beulich wrote: >> On 13.12.2019 14:53, Durrant, Paul wrote: >>> Since *not* having the 'sink' page allows a guest pull off a host DoS >>> in the presence of such h/w, security is surely increased by having it? >> >> host device result w/o sink result w/ sink >> good goodgoodgood >> good babblinggoodgood >> wedge on fault goodDoS (runtime) DoS (runtime) > > I guess the DoS cases here are due to malicious guest actions? Yes. >> wedge on fault babblingDoS (runtime/late) DoS (runtime >> only, silent) > > And why is the sink page resulting in a silent DoS here? Sorry, space restrictions may have lead to this being ambiguous: There's still the runtime DoS; the would-be-DoS after deassignment will go entirely silent (i.e. without making the admin aware of the situation, not allowing them to take precautions against the runtime aspects of this). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.19 15:23, Jan Beulich wrote: On 13.12.2019 14:53, Durrant, Paul wrote: Since *not* having the 'sink' page allows a guest pull off a host DoS in the presence of such h/w, security is surely increased by having it? hostdevice result w/o sink result w/ sink goodgoodgoodgood goodbabblinggoodgood wedge on fault goodDoS (runtime) DoS (runtime) I guess the DoS cases here are due to malicious guest actions? wedge on fault babblingDoS (runtime/late) DoS (runtime only, silent) And why is the sink page resulting in a silent DoS here? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.19 15:11, Jan Beulich wrote: On 13.12.2019 14:46, Jürgen Groß wrote: On 13.12.19 14:38, Jan Beulich wrote: On 13.12.2019 14:31, Jürgen Groß wrote: Maybe I have misunderstood the current state, but I thought that it would just silently hide quirky devices without imposing a security risk. We would not learn which devices are quirky, but OTOH I doubt we'd get many reports about those in case your patch goes in. We don't want or need such reports, that's not the point. The security risk comes from the quirkiness of the devices - admins may wrongly think all is well and expose quirky devices to not sufficiently trusted guests. (I say this fully realizing that exposing devices to untrusted guests is almost always a certain level of risk.) Do we _know_ those devices are problematic from security standpoint? Normally the IOMMU should do the isolation just fine. If it doesn't then its not the quirky device which is problematic, but the IOMMU. I thought the problem was that the quirky devices would not stop all (read) DMA even when being unassigned from the guest resulting in fatal IOMMU faults. The dummy page should stop those faults to happen resulting in a more stable system. IOMMU faults by themselves are not impacting stability (they will add processing overhead, yes). The problem, according to Paul's description, is that the occurrence of at least some forms of IOMMU faults (not present ones as it seems, as opposed to permission violation ones) is fatal to certain systems. Irrespective of the sink page used after de-assignment a guest can arrange for IOMMU faults to occur even while it still has the device assigned. Hence it is important for the admin to know that their system (not the the particular device) behaves in this undesirable way. So how does the admin learn this? Its not as if your patch would result in a system crash or hang all the time, right? This would be the case only if there either is a malicious (on purpose or due to a bug) guest which gets the device assigned, or if there happens to be a pending DMA operation when the device gets unassigned. The malicious guest case would be caught without your patch as well. And most cases of device unassignment would be fine, too, as a normal guest shutdown/reboot includes stopping I/O activity. So what are the security problems which are added by this behavior? There are no problems added; there are problems hidden from admins. In my understanding in some corner cases, yes. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 14:53, Durrant, Paul wrote: > Since *not* having the 'sink' page allows a guest pull off a host DoS > in the presence of such h/w, security is surely increased by having it? hostdevice result w/o sink result w/ sink goodgoodgoodgood goodbabblinggoodgood wedge on fault goodDoS (runtime) DoS (runtime) wedge on fault babblingDoS (runtime/late) DoS (runtime only, silent) I wouldn't call it an increase of security to fully hide post- deassignment issues without doing anything about issues that can arise while the device is still assigned. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 14:46, Jürgen Groß wrote: > On 13.12.19 14:38, Jan Beulich wrote: >> On 13.12.2019 14:31, Jürgen Groß wrote: >>> Maybe I have misunderstood the current state, but I thought that it >>> would just silently hide quirky devices without imposing a security >>> risk. We would not learn which devices are quirky, but OTOH I doubt >>> we'd get many reports about those in case your patch goes in. >> >> We don't want or need such reports, that's not the point. The >> security risk comes from the quirkiness of the devices - admins >> may wrongly think all is well and expose quirky devices to not >> sufficiently trusted guests. (I say this fully realizing that >> exposing devices to untrusted guests is almost always a certain >> level of risk.) > > Do we _know_ those devices are problematic from security standpoint? > Normally the IOMMU should do the isolation just fine. If it doesn't > then its not the quirky device which is problematic, but the IOMMU. > > I thought the problem was that the quirky devices would not stop all > (read) DMA even when being unassigned from the guest resulting in > fatal IOMMU faults. The dummy page should stop those faults to happen > resulting in a more stable system. IOMMU faults by themselves are not impacting stability (they will add processing overhead, yes). The problem, according to Paul's description, is that the occurrence of at least some forms of IOMMU faults (not present ones as it seems, as opposed to permission violation ones) is fatal to certain systems. Irrespective of the sink page used after de-assignment a guest can arrange for IOMMU faults to occur even while it still has the device assigned. Hence it is important for the admin to know that their system (not the the particular device) behaves in this undesirable way. > So what are the security problems which are added by this behavior? There are no problems added; there are problems hidden from admins. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On Fri, Dec 13, 2019 at 01:53:29PM +0100, Jan Beulich wrote:
> Containing still in flight DMA was introduced to work around certain
> devices / systems hanging hard upon hitting an IOMMU fault. Passing
> through (such) devices (on such systems) is inherently insecure (as
> guests could easily arrange for IOMMU faults to occur). Defaulting to
> a mode where admins may not even become aware of issues with devices can
> be considered undesirable. Therefore convert this mode of operation to
> an optional one, not one enabled by default.
>
> This involves resurrecting code commit ea38867831da ("x86 / iommu: set
> up a scratch page in the quarantine domain") did remove, in a slightly
> extended and abstracted fashion. Here, instead of reintroducing a pretty
> pointless use of "goto" in domain_context_unmap(), and instead of making
> the function (at least temporarily) inconsistent, take the opportunity
> and replace the other similarly pointless "goto" as well.
>
> In order to key the re-instated bypasses off of there (not) being a root
> page table this further requires moving the allocate_domain_resources()
> invocation from reassign_device() to amd_iommu_setup_domain_device() (or
> else reassign_device() would allocate a root page table anyway); this is
> benign to the second caller of the latter function.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
I'm however not sure if the default quarantine mode should be the
basic or the full one.
At the end of day the full one does prevent hard hangs on specific
systems, but a guest with a device behind such bogus IOMMU can
trivially trigger those anyway.
> ---
> As far as 4.13 is concerned, I guess if we can't come to an agreement
> here, the only other option is to revert ea38867831da from the branch,
> for having been committed prematurely (I'm not so much worried about the
> master branch, where we have ample time until 4.14). What I surely want
> to see us avoid is a back and forth in behavior of released versions.
> (Note that 4.12.2 is similarly blocked on a decision either way here.)
>
> I'm happy to take better suggestions to replace "full".
I was going to comment on v1, but I really have no better alternative.
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -30,13 +30,17 @@ bool_t __initdata iommu_enable = 1;
> bool_t __read_mostly iommu_enabled;
> bool_t __read_mostly force_iommu;
> bool_t __read_mostly iommu_verbose;
> -bool __read_mostly iommu_quarantine = true;
> bool_t __read_mostly iommu_igfx = 1;
> bool_t __read_mostly iommu_snoop = 1;
> bool_t __read_mostly iommu_qinval = 1;
> bool_t __read_mostly iommu_intremap = 1;
> bool_t __read_mostly iommu_crash_disable;
>
> +#define IOMMU_quarantine_none 0
> +#define IOMMU_quarantine_basic 1
> +#define IOMMU_quarantine_full 2
> +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic;
I wonder whether the default should be to use the sink page. Not using
it can lead to a hard hang on certain hardware according to the
description. OTOH if such devices are actually passed through, the
guest itself can trigger such page faults and hence freeze the system.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
> -Original Message-
> From: Xen-devel On Behalf Of
> Jürgen Groß
> Sent: 13 December 2019 13:47
> To: Jan Beulich
> Cc: Kevin Tian ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Paul Durrant ; Ian Jackson ; xen-
> de...@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of
> quarantined devices optional
>
> On 13.12.19 14:38, Jan Beulich wrote:
> > On 13.12.2019 14:31, Jürgen Groß wrote:
> >> On 13.12.19 14:21, Jan Beulich wrote:
> >>> On 13.12.2019 14:11, Jürgen Groß wrote:
> >>>> On 13.12.19 13:53, Jan Beulich wrote:
> >>>>> Containing still in flight DMA was introduced to work around certain
> >>>>> devices / systems hanging hard upon hitting an IOMMU fault. Passing
> >>>>> through (such) devices (on such systems) is inherently insecure (as
> >>>>> guests could easily arrange for IOMMU faults to occur). Defaulting
> to
> >>>>> a mode where admins may not even become aware of issues with devices
> can
> >>>>> be considered undesirable. Therefore convert this mode of operation
> to
> >>>>> an optional one, not one enabled by default.
> >>>>>
> >>>>> This involves resurrecting code commit ea38867831da ("x86 / iommu:
> set
> >>>>> up a scratch page in the quarantine domain") did remove, in a
> slightly
> >>>>> extended and abstracted fashion. Here, instead of reintroducing a
> pretty
> >>>>> pointless use of "goto" in domain_context_unmap(), and instead of
> making
> >>>>> the function (at least temporarily) inconsistent, take the
> opportunity
> >>>>> and replace the other similarly pointless "goto" as well.
> >>>>>
> >>>>> In order to key the re-instated bypasses off of there (not) being a
> root
> >>>>> page table this further requires moving the
> allocate_domain_resources()
> >>>>> invocation from reassign_device() to amd_iommu_setup_domain_device()
> (or
> >>>>> else reassign_device() would allocate a root page table anyway);
> this is
> >>>>> benign to the second caller of the latter function.
> >>>>>
> >>>>> Signed-off-by: Jan Beulich
> >>>>> ---
> >>>>> As far as 4.13 is concerned, I guess if we can't come to an
> agreement
> >>>>> here, the only other option is to revert ea38867831da from the
> branch,
> >>>>> for having been committed prematurely (I'm not so much worried about
> the
> >>>>> master branch, where we have ample time until 4.14). What I surely
> want
> >>>>> to see us avoid is a back and forth in behavior of released
> versions.
> >>>>> (Note that 4.12.2 is similarly blocked on a decision either way
> here.)
> >>>>
> >>>> I'm not really sure we really need to revert ea38867831da before the
> >>>> 4.13 release. It might not be optimal, but I'm quite sure the number
> of
> >>>> cases where this could be an issue is rather small already, and I
> tend
> >>>> to agree with Paul that admins who really care will more likely want
> to
> >>>> select the option where the system will "just work". IMO the
> "noticeable
> >>>> failure" is something which will be selected mostly by developers.
> But
> >>>> I'm not an expert in that area, so I don't want to influence the
> >>>> decision regarding the to be selected default too much.
> >>>
> >>> An admin not wanting to know is, to me, the same as them not wanting
> >>> to know about security issues, and hence not subscribing to our
> >>> announcements lists. I can accept this being a reasonable thing to
> >>> do when it is an _informed_ decision. But with the current
> >>> arrangements there's no way whatsoever for an admin to know.
> >>
> >> Maybe I have misunderstood the current state, but I thought that it
> >> would just silently hide quirky devices without imposing a security
> >> risk. We would not learn which devices are quirky, but OTOH I doubt
> >> we'd get many reports about those in case your patch goes in.
> >
> > We don't want or need such reports, that's not the point. The
> > security
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
On 13.12.19 14:21, Jan Beulich wrote:
On 13.12.2019 14:11, Jürgen Groß wrote:
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) is inherently insecure (as
guests could easily arrange for IOMMU faults to occur). Defaulting to
a mode where admins may not even become aware of issues with devices can
be considered undesirable. Therefore convert this mode of operation to
an optional one, not one enabled by default.
This involves resurrecting code commit ea38867831da ("x86 / iommu: set
up a scratch page in the quarantine domain") did remove, in a slightly
extended and abstracted fashion. Here, instead of reintroducing a pretty
pointless use of "goto" in domain_context_unmap(), and instead of making
the function (at least temporarily) inconsistent, take the opportunity
and replace the other similarly pointless "goto" as well.
In order to key the re-instated bypasses off of there (not) being a root
page table this further requires moving the allocate_domain_resources()
invocation from reassign_device() to amd_iommu_setup_domain_device() (or
else reassign_device() would allocate a root page table anyway); this is
benign to the second caller of the latter function.
Signed-off-by: Jan Beulich
---
As far as 4.13 is concerned, I guess if we can't come to an agreement
here, the only other option is to revert ea38867831da from the branch,
for having been committed prematurely (I'm not so much worried about the
master branch, where we have ample time until 4.14). What I surely want
to see us avoid is a back and forth in behavior of released versions.
(Note that 4.12.2 is similarly blocked on a decision either way here.)
I'm not really sure we really need to revert ea38867831da before the
4.13 release. It might not be optimal, but I'm quite sure the number of
cases where this could be an issue is rather small already, and I tend
to agree with Paul that admins who really care will more likely want to
select the option where the system will "just work". IMO the "noticeable
failure" is something which will be selected mostly by developers. But
I'm not an expert in that area, so I don't want to influence the
decision regarding the to be selected default too much.
An admin not wanting to know is, to me, the same as them not wanting
to know about security issues, and hence not subscribing to our
announcements lists. I can accept this being a reasonable thing to
do when it is an _informed_ decision. But with the current
arrangements there's no way whatsoever for an admin to know.
Maybe I have misunderstood the current state, but I thought that it
would just silently hide quirky devices without imposing a security
risk. We would not learn which devices are quirky, but OTOH I doubt
we'd get many reports about those in case your patch goes in.
We don't want or need such reports, that's not the point. The
security risk comes from the quirkiness of the devices - admins
may wrongly think all is well and expose quirky devices to not
sufficiently trusted guests. (I say this fully realizing that
exposing devices to untrusted guests is almost always a certain
level of risk.)
Do we _know_ those devices are problematic from security standpoint?
Normally the IOMMU should do the isolation just fine. If it doesn't
then its not the quirky device which is problematic, but the IOMMU.
I thought the problem was that the quirky devices would not stop all
(read) DMA even when being unassigned from the guest resulting in
fatal IOMMU faults. The dummy page should stop those faults to happen
resulting in a more stable system.
So what are the security problems which are added by this behavior?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 14:31, Jürgen Groß wrote:
> On 13.12.19 14:21, Jan Beulich wrote:
>> On 13.12.2019 14:11, Jürgen Groß wrote:
>>> On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) is inherently insecure (as
guests could easily arrange for IOMMU faults to occur). Defaulting to
a mode where admins may not even become aware of issues with devices can
be considered undesirable. Therefore convert this mode of operation to
an optional one, not one enabled by default.
This involves resurrecting code commit ea38867831da ("x86 / iommu: set
up a scratch page in the quarantine domain") did remove, in a slightly
extended and abstracted fashion. Here, instead of reintroducing a pretty
pointless use of "goto" in domain_context_unmap(), and instead of making
the function (at least temporarily) inconsistent, take the opportunity
and replace the other similarly pointless "goto" as well.
In order to key the re-instated bypasses off of there (not) being a root
page table this further requires moving the allocate_domain_resources()
invocation from reassign_device() to amd_iommu_setup_domain_device() (or
else reassign_device() would allocate a root page table anyway); this is
benign to the second caller of the latter function.
Signed-off-by: Jan Beulich
---
As far as 4.13 is concerned, I guess if we can't come to an agreement
here, the only other option is to revert ea38867831da from the branch,
for having been committed prematurely (I'm not so much worried about the
master branch, where we have ample time until 4.14). What I surely want
to see us avoid is a back and forth in behavior of released versions.
(Note that 4.12.2 is similarly blocked on a decision either way here.)
>>>
>>> I'm not really sure we really need to revert ea38867831da before the
>>> 4.13 release. It might not be optimal, but I'm quite sure the number of
>>> cases where this could be an issue is rather small already, and I tend
>>> to agree with Paul that admins who really care will more likely want to
>>> select the option where the system will "just work". IMO the "noticeable
>>> failure" is something which will be selected mostly by developers. But
>>> I'm not an expert in that area, so I don't want to influence the
>>> decision regarding the to be selected default too much.
>>
>> An admin not wanting to know is, to me, the same as them not wanting
>> to know about security issues, and hence not subscribing to our
>> announcements lists. I can accept this being a reasonable thing to
>> do when it is an _informed_ decision. But with the current
>> arrangements there's no way whatsoever for an admin to know.
>
> Maybe I have misunderstood the current state, but I thought that it
> would just silently hide quirky devices without imposing a security
> risk. We would not learn which devices are quirky, but OTOH I doubt
> we'd get many reports about those in case your patch goes in.
We don't want or need such reports, that's not the point. The
security risk comes from the quirkiness of the devices - admins
may wrongly think all is well and expose quirky devices to not
sufficiently trusted guests. (I say this fully realizing that
exposing devices to untrusted guests is almost always a certain
level of risk.)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 14:29, Durrant, Paul wrote: >> From: Jan Beulich >> Sent: 13 December 2019 13:26 >> >> On 13.12.2019 14:12, Durrant, Paul wrote: From: Xen-devel On Behalf Of Jan Beulich Sent: 13 December 2019 12:53 +#define IOMMU_quarantine_none 0 +#define IOMMU_quarantine_basic 1 +#define IOMMU_quarantine_full 2 +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic; >>> >>> If we have 'IOMMU_quarantine_sink' instead of 'IOMMU_quarantine_full', >>> then how about 'IOMMU_quarantine_write_fault' instead of >>> 'IOMMU_quarantine_basic'? >> >> Why "write_fault"? Even in "full" mode you only avoid read faults >> aiui (see also above). So if anything "write_fault" would be a >> replacement for "full"; "basic" could be replaced by just "fault" >> then. > > Sorry, yes, I had things the wrong way round. "fault" and "write_fault" sound > good. But the resulting command line option (iommu=quarantine=write-fault) would then be quite a bit less nice imo, compare to the brief "full". (I'm tempted to suggest "nrf" for "no read fault", but I guess that's too ugly an acronym.) Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.19 14:21, Jan Beulich wrote:
On 13.12.2019 14:11, Jürgen Groß wrote:
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) is inherently insecure (as
guests could easily arrange for IOMMU faults to occur). Defaulting to
a mode where admins may not even become aware of issues with devices can
be considered undesirable. Therefore convert this mode of operation to
an optional one, not one enabled by default.
This involves resurrecting code commit ea38867831da ("x86 / iommu: set
up a scratch page in the quarantine domain") did remove, in a slightly
extended and abstracted fashion. Here, instead of reintroducing a pretty
pointless use of "goto" in domain_context_unmap(), and instead of making
the function (at least temporarily) inconsistent, take the opportunity
and replace the other similarly pointless "goto" as well.
In order to key the re-instated bypasses off of there (not) being a root
page table this further requires moving the allocate_domain_resources()
invocation from reassign_device() to amd_iommu_setup_domain_device() (or
else reassign_device() would allocate a root page table anyway); this is
benign to the second caller of the latter function.
Signed-off-by: Jan Beulich
---
As far as 4.13 is concerned, I guess if we can't come to an agreement
here, the only other option is to revert ea38867831da from the branch,
for having been committed prematurely (I'm not so much worried about the
master branch, where we have ample time until 4.14). What I surely want
to see us avoid is a back and forth in behavior of released versions.
(Note that 4.12.2 is similarly blocked on a decision either way here.)
I'm not really sure we really need to revert ea38867831da before the
4.13 release. It might not be optimal, but I'm quite sure the number of
cases where this could be an issue is rather small already, and I tend
to agree with Paul that admins who really care will more likely want to
select the option where the system will "just work". IMO the "noticeable
failure" is something which will be selected mostly by developers. But
I'm not an expert in that area, so I don't want to influence the
decision regarding the to be selected default too much.
An admin not wanting to know is, to me, the same as them not wanting
to know about security issues, and hence not subscribing to our
announcements lists. I can accept this being a reasonable thing to
do when it is an _informed_ decision. But with the current
arrangements there's no way whatsoever for an admin to know.
Maybe I have misunderstood the current state, but I thought that it
would just silently hide quirky devices without imposing a security
risk. We would not learn which devices are quirky, but OTOH I doubt
we'd get many reports about those in case your patch goes in.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
> -Original Message-
> From: Jan Beulich
> Sent: 13 December 2019 13:26
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Juergen Gross ; Kevin
> Tian ; Stefano Stabellini ;
> Julien Grall ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian Jackson ; Roger Pau Monné
>
> Subject: Re: [PATCH v2] IOMMU: make DMA containment of quarantined devices
> optional
>
> On 13.12.2019 14:12, Durrant, Paul wrote:
> >> -Original Message-
> >> From: Xen-devel On Behalf Of
> Jan
> >> Beulich
> >> Sent: 13 December 2019 12:53
> >> To: xen-devel@lists.xenproject.org
> >> Cc: Juergen Gross ; Kevin Tian ;
> >> Stefano Stabellini ; Julien Grall
> >> ; Wei Liu ; Konrad Wilk
> >> ; George Dunlap ;
> >> Andrew Cooper ; Paul Durrant ;
> >> Ian Jackson ; Roger Pau Monné
> >>
> >> Subject: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of
> quarantined
> >> devices optional
> >>
> >> Containing still in flight DMA was introduced to work around certain
> >> devices / systems hanging hard upon hitting an IOMMU fault. Passing
> >> through (such) devices (on such systems) is inherently insecure (as
> >> guests could easily arrange for IOMMU faults to occur). Defaulting to
> >> a mode where admins may not even become aware of issues with devices
> can
> >> be considered undesirable. Therefore convert this mode of operation to
> >> an optional one, not one enabled by default.
> >>
> >> This involves resurrecting code commit ea38867831da ("x86 / iommu: set
> >> up a scratch page in the quarantine domain") did remove, in a slightly
> >> extended and abstracted fashion. Here, instead of reintroducing a
> pretty
> >> pointless use of "goto" in domain_context_unmap(), and instead of
> making
> >> the function (at least temporarily) inconsistent, take the opportunity
> >> and replace the other similarly pointless "goto" as well.
> >>
> >> In order to key the re-instated bypasses off of there (not) being a
> root
> >> page table this further requires moving the allocate_domain_resources()
> >> invocation from reassign_device() to amd_iommu_setup_domain_device()
> (or
> >> else reassign_device() would allocate a root page table anyway); this
> is
> >> benign to the second caller of the latter function.
> >>
> >> Signed-off-by: Jan Beulich
> >> ---
> >> As far as 4.13 is concerned, I guess if we can't come to an agreement
> >> here, the only other option is to revert ea38867831da from the branch,
> >> for having been committed prematurely (I'm not so much worried about
> the
> >> master branch, where we have ample time until 4.14). What I surely want
> >> to see us avoid is a back and forth in behavior of released versions.
> >> (Note that 4.12.2 is similarly blocked on a decision either way here.)
> >>
> >> I'm happy to take better suggestions to replace "full".
> >
> > How about simply "sink", since that's what it does?
>
> But it's not really a "sink", as we still fault writes (which is the
> only thing I can see to be "sunk" if I'm getting the meaning of the
> word right).
>
> >> --- a/xen/drivers/passthrough/iommu.c
> >> +++ b/xen/drivers/passthrough/iommu.c
> >> @@ -30,13 +30,17 @@ bool_t __initdata iommu_enable = 1;
> >> bool_t __read_mostly iommu_enabled;
> >> bool_t __read_mostly force_iommu;
> >> bool_t __read_mostly iommu_verbose;
> >> -bool __read_mostly iommu_quarantine = true;
> >> bool_t __read_mostly iommu_igfx = 1;
> >> bool_t __read_mostly iommu_snoop = 1;
> >> bool_t __read_mostly iommu_qinval = 1;
> >> bool_t __read_mostly iommu_intremap = 1;
> >> bool_t __read_mostly iommu_crash_disable;
> >>
> >> +#define IOMMU_quarantine_none 0
> >> +#define IOMMU_quarantine_basic 1
> >> +#define IOMMU_quarantine_full 2
> >> +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic;
> >
> > If we have 'IOMMU_quarantine_sink' instead of 'IOMMU_quarantine_full',
> > then how about 'IOMMU_quarantine_write_fault' instead of
> > 'IOMMU_quarantine_basic'?
>
> Why "write_fault"? Even in "full" mode you only avoid read faults
> aiui (see also above). So if anything "write_fault" would be a
> replacement for "full"; "basic" could be replaced by just "fault"
> then.
Sorry, yes, I had things the wrong way round. "fault" and "write_fault" sound
good.
Paul
>
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 14:12, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 13 December 2019 12:53
>> To: xen-devel@lists.xenproject.org
>> Cc: Juergen Gross ; Kevin Tian ;
>> Stefano Stabellini ; Julien Grall
>> ; Wei Liu ; Konrad Wilk
>> ; George Dunlap ;
>> Andrew Cooper ; Paul Durrant ;
>> Ian Jackson ; Roger Pau Monné
>>
>> Subject: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined
>> devices optional
>>
>> Containing still in flight DMA was introduced to work around certain
>> devices / systems hanging hard upon hitting an IOMMU fault. Passing
>> through (such) devices (on such systems) is inherently insecure (as
>> guests could easily arrange for IOMMU faults to occur). Defaulting to
>> a mode where admins may not even become aware of issues with devices can
>> be considered undesirable. Therefore convert this mode of operation to
>> an optional one, not one enabled by default.
>>
>> This involves resurrecting code commit ea38867831da ("x86 / iommu: set
>> up a scratch page in the quarantine domain") did remove, in a slightly
>> extended and abstracted fashion. Here, instead of reintroducing a pretty
>> pointless use of "goto" in domain_context_unmap(), and instead of making
>> the function (at least temporarily) inconsistent, take the opportunity
>> and replace the other similarly pointless "goto" as well.
>>
>> In order to key the re-instated bypasses off of there (not) being a root
>> page table this further requires moving the allocate_domain_resources()
>> invocation from reassign_device() to amd_iommu_setup_domain_device() (or
>> else reassign_device() would allocate a root page table anyway); this is
>> benign to the second caller of the latter function.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> As far as 4.13 is concerned, I guess if we can't come to an agreement
>> here, the only other option is to revert ea38867831da from the branch,
>> for having been committed prematurely (I'm not so much worried about the
>> master branch, where we have ample time until 4.14). What I surely want
>> to see us avoid is a back and forth in behavior of released versions.
>> (Note that 4.12.2 is similarly blocked on a decision either way here.)
>>
>> I'm happy to take better suggestions to replace "full".
>
> How about simply "sink", since that's what it does?
But it's not really a "sink", as we still fault writes (which is the
only thing I can see to be "sunk" if I'm getting the meaning of the
word right).
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -30,13 +30,17 @@ bool_t __initdata iommu_enable = 1;
>> bool_t __read_mostly iommu_enabled;
>> bool_t __read_mostly force_iommu;
>> bool_t __read_mostly iommu_verbose;
>> -bool __read_mostly iommu_quarantine = true;
>> bool_t __read_mostly iommu_igfx = 1;
>> bool_t __read_mostly iommu_snoop = 1;
>> bool_t __read_mostly iommu_qinval = 1;
>> bool_t __read_mostly iommu_intremap = 1;
>> bool_t __read_mostly iommu_crash_disable;
>>
>> +#define IOMMU_quarantine_none 0
>> +#define IOMMU_quarantine_basic 1
>> +#define IOMMU_quarantine_full 2
>> +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic;
>
> If we have 'IOMMU_quarantine_sink' instead of 'IOMMU_quarantine_full',
> then how about 'IOMMU_quarantine_write_fault' instead of
> 'IOMMU_quarantine_basic'?
Why "write_fault"? Even in "full" mode you only avoid read faults
aiui (see also above). So if anything "write_fault" would be a
replacement for "full"; "basic" could be replaced by just "fault"
then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.2019 14:11, Jürgen Groß wrote:
> On 13.12.19 13:53, Jan Beulich wrote:
>> Containing still in flight DMA was introduced to work around certain
>> devices / systems hanging hard upon hitting an IOMMU fault. Passing
>> through (such) devices (on such systems) is inherently insecure (as
>> guests could easily arrange for IOMMU faults to occur). Defaulting to
>> a mode where admins may not even become aware of issues with devices can
>> be considered undesirable. Therefore convert this mode of operation to
>> an optional one, not one enabled by default.
>>
>> This involves resurrecting code commit ea38867831da ("x86 / iommu: set
>> up a scratch page in the quarantine domain") did remove, in a slightly
>> extended and abstracted fashion. Here, instead of reintroducing a pretty
>> pointless use of "goto" in domain_context_unmap(), and instead of making
>> the function (at least temporarily) inconsistent, take the opportunity
>> and replace the other similarly pointless "goto" as well.
>>
>> In order to key the re-instated bypasses off of there (not) being a root
>> page table this further requires moving the allocate_domain_resources()
>> invocation from reassign_device() to amd_iommu_setup_domain_device() (or
>> else reassign_device() would allocate a root page table anyway); this is
>> benign to the second caller of the latter function.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> As far as 4.13 is concerned, I guess if we can't come to an agreement
>> here, the only other option is to revert ea38867831da from the branch,
>> for having been committed prematurely (I'm not so much worried about the
>> master branch, where we have ample time until 4.14). What I surely want
>> to see us avoid is a back and forth in behavior of released versions.
>> (Note that 4.12.2 is similarly blocked on a decision either way here.)
>
> I'm not really sure we really need to revert ea38867831da before the
> 4.13 release. It might not be optimal, but I'm quite sure the number of
> cases where this could be an issue is rather small already, and I tend
> to agree with Paul that admins who really care will more likely want to
> select the option where the system will "just work". IMO the "noticeable
> failure" is something which will be selected mostly by developers. But
> I'm not an expert in that area, so I don't want to influence the
> decision regarding the to be selected default too much.
An admin not wanting to know is, to me, the same as them not wanting
to know about security issues, and hence not subscribing to our
announcements lists. I can accept this being a reasonable thing to
do when it is an _informed_ decision. But with the current
arrangements there's no way whatsoever for an admin to know.
Furthermore, once we ship a release with the defaults as they
currently are, changing the defaults again may be perceived as a
regression, which I think we should (want to) avoid.
> In case we have a successful OSStest run soon I planned to do the
> release without this patch.
I very much disagree - the patch shouldn't have been put in without
having heard back from Kevin. But yes, you're the release manager.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) is inherently insecure (as
guests could easily arrange for IOMMU faults to occur). Defaulting to
a mode where admins may not even become aware of issues with devices can
be considered undesirable. Therefore convert this mode of operation to
an optional one, not one enabled by default.
This involves resurrecting code commit ea38867831da ("x86 / iommu: set
up a scratch page in the quarantine domain") did remove, in a slightly
extended and abstracted fashion. Here, instead of reintroducing a pretty
pointless use of "goto" in domain_context_unmap(), and instead of making
the function (at least temporarily) inconsistent, take the opportunity
and replace the other similarly pointless "goto" as well.
In order to key the re-instated bypasses off of there (not) being a root
page table this further requires moving the allocate_domain_resources()
invocation from reassign_device() to amd_iommu_setup_domain_device() (or
else reassign_device() would allocate a root page table anyway); this is
benign to the second caller of the latter function.
Signed-off-by: Jan Beulich
---
As far as 4.13 is concerned, I guess if we can't come to an agreement
here, the only other option is to revert ea38867831da from the branch,
for having been committed prematurely (I'm not so much worried about the
master branch, where we have ample time until 4.14). What I surely want
to see us avoid is a back and forth in behavior of released versions.
(Note that 4.12.2 is similarly blocked on a decision either way here.)
I'm not really sure we really need to revert ea38867831da before the
4.13 release. It might not be optimal, but I'm quite sure the number of
cases where this could be an issue is rather small already, and I tend
to agree with Paul that admins who really care will more likely want to
select the option where the system will "just work". IMO the "noticeable
failure" is something which will be selected mostly by developers. But
I'm not an expert in that area, so I don't want to influence the
decision regarding the to be selected default too much.
In case we have a successful OSStest run soon I planned to do the
release without this patch.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined devices optional
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 13 December 2019 12:53
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Kevin Tian ;
> Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian Jackson ; Roger Pau Monné
>
> Subject: [Xen-devel] [PATCH v2] IOMMU: make DMA containment of quarantined
> devices optional
>
> Containing still in flight DMA was introduced to work around certain
> devices / systems hanging hard upon hitting an IOMMU fault. Passing
> through (such) devices (on such systems) is inherently insecure (as
> guests could easily arrange for IOMMU faults to occur). Defaulting to
> a mode where admins may not even become aware of issues with devices can
> be considered undesirable. Therefore convert this mode of operation to
> an optional one, not one enabled by default.
>
> This involves resurrecting code commit ea38867831da ("x86 / iommu: set
> up a scratch page in the quarantine domain") did remove, in a slightly
> extended and abstracted fashion. Here, instead of reintroducing a pretty
> pointless use of "goto" in domain_context_unmap(), and instead of making
> the function (at least temporarily) inconsistent, take the opportunity
> and replace the other similarly pointless "goto" as well.
>
> In order to key the re-instated bypasses off of there (not) being a root
> page table this further requires moving the allocate_domain_resources()
> invocation from reassign_device() to amd_iommu_setup_domain_device() (or
> else reassign_device() would allocate a root page table anyway); this is
> benign to the second caller of the latter function.
>
> Signed-off-by: Jan Beulich
> ---
> As far as 4.13 is concerned, I guess if we can't come to an agreement
> here, the only other option is to revert ea38867831da from the branch,
> for having been committed prematurely (I'm not so much worried about the
> master branch, where we have ample time until 4.14). What I surely want
> to see us avoid is a back and forth in behavior of released versions.
> (Note that 4.12.2 is similarly blocked on a decision either way here.)
>
> I'm happy to take better suggestions to replace "full".
How about simply "sink", since that's what it does?
[snip]
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -30,13 +30,17 @@ bool_t __initdata iommu_enable = 1;
> bool_t __read_mostly iommu_enabled;
> bool_t __read_mostly force_iommu;
> bool_t __read_mostly iommu_verbose;
> -bool __read_mostly iommu_quarantine = true;
> bool_t __read_mostly iommu_igfx = 1;
> bool_t __read_mostly iommu_snoop = 1;
> bool_t __read_mostly iommu_qinval = 1;
> bool_t __read_mostly iommu_intremap = 1;
> bool_t __read_mostly iommu_crash_disable;
>
> +#define IOMMU_quarantine_none 0
> +#define IOMMU_quarantine_basic 1
> +#define IOMMU_quarantine_full 2
> +uint8_t __read_mostly iommu_quarantine = IOMMU_quarantine_basic;
If we have 'IOMMU_quarantine_sink' instead of 'IOMMU_quarantine_full', then how
about 'IOMMU_quarantine_write_fault' instead of 'IOMMU_quarantine_basic'?
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
