| Message ID | de75b36b3b31cd328de3811c0725f3d0af448abc.1627468310.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iommu: Refactor DMA domain strictness | expand |
On 7/28/21 11:58 PM, Robin Murphy wrote: > Allocating and enabling a flush queue is in fact something we can > reasonably do while a DMA domain is active, without having to rebuild it > from scratch. Thus we can allow a strict -> non-strict transition from > sysfs without requiring to unbind the device's driver, which is of > particular interest to users who want to make selective relaxations to > critical devices like the one serving their root filesystem. > > Disabling and draining a queue also seems technically possible to > achieve without rebuilding the whole domain, but would certainly be more > involved. Furthermore there's not such a clear use-case for tightening > up security *after* the device may already have done whatever it is that > you don't trust it not to do, so we only consider the relaxation case. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > --- > drivers/iommu/iommu.c | 16 ++++++++++++---- > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 25c1adc1ec67..be399d630953 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -3200,6 +3200,13 @@ static int iommu_change_dev_def_domain(struct iommu_group *group, > goto out; > } > > + /* We can bring up a flush queue without tearing down the domain */ > + if (type == IOMMU_DOMAIN_DMA_FQ && prev_dom->type == IOMMU_DOMAIN_DMA) { > + prev_dom->type = IOMMU_DOMAIN_DMA_FQ; > + ret = iommu_dma_init_fq(prev_dom); > + goto out; > + } > + > /* Sets group->default_domain to the newly allocated domain */ > ret = iommu_group_alloc_default_domain(dev->bus, group, type); > if (ret) > @@ -3240,9 +3247,9 @@ static int iommu_change_dev_def_domain(struct iommu_group *group, > } > > /* > - * Changing the default domain through sysfs requires the users to ubind the > - * drivers from the devices in the iommu group. Return failure if this doesn't > - * meet. > + * Changing the default domain through sysfs requires the users to unbind the > + * drivers from the devices in the iommu group, except for a DMA -> DMA-FQ > + * transition. Return failure if this isn't met. > * > * We need to consider the race between this and the device release path. > * device_lock(dev) is used here to guarantee that the device release path > @@ -3318,7 +3325,8 @@ static ssize_t iommu_group_store_type(struct iommu_group *group, > > /* Check if the device in the group still has a driver bound to it */ > device_lock(dev); > - if (device_is_bound(dev)) { > + if (device_is_bound(dev) && !(req_type == IOMMU_DOMAIN_DMA_FQ && > + group->default_domain->type == IOMMU_DOMAIN_DMA)) { > pr_err_ratelimited("Device is still bound to driver\n"); > ret = -EBUSY; > goto out; > Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu
On 28/07/2021 16:58, Robin Murphy wrote: > Allocating and enabling a flush queue is in fact something we can > reasonably do while a DMA domain is active, without having to rebuild it > from scratch. Thus we can allow a strict -> non-strict transition from > sysfs without requiring to unbind the device's driver, which is of > particular interest to users who want to make selective relaxations to > critical devices like the one serving their root filesystem. > > Disabling and draining a queue also seems technically possible to > achieve without rebuilding the whole domain, but would certainly be more > involved. Furthermore there's not such a clear use-case for tightening > up security*after* the device may already have done whatever it is that > you don't trust it not to do, so we only consider the relaxation case. > > Signed-off-by: Robin Murphy<robin.murphy@arm.com> Reviewed-by: John Garry <john.garry@huawei.com>
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 25c1adc1ec67..be399d630953 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -3200,6 +3200,13 @@ static int iommu_change_dev_def_domain(struct iommu_group *group, goto out; } + /* We can bring up a flush queue without tearing down the domain */ + if (type == IOMMU_DOMAIN_DMA_FQ && prev_dom->type == IOMMU_DOMAIN_DMA) { + prev_dom->type = IOMMU_DOMAIN_DMA_FQ; + ret = iommu_dma_init_fq(prev_dom); + goto out; + } + /* Sets group->default_domain to the newly allocated domain */ ret = iommu_group_alloc_default_domain(dev->bus, group, type); if (ret) @@ -3240,9 +3247,9 @@ static int iommu_change_dev_def_domain(struct iommu_group *group, } /* - * Changing the default domain through sysfs requires the users to ubind the - * drivers from the devices in the iommu group. Return failure if this doesn't - * meet. + * Changing the default domain through sysfs requires the users to unbind the + * drivers from the devices in the iommu group, except for a DMA -> DMA-FQ + * transition. Return failure if this isn't met. * * We need to consider the race between this and the device release path. * device_lock(dev) is used here to guarantee that the device release path @@ -3318,7 +3325,8 @@ static ssize_t iommu_group_store_type(struct iommu_group *group, /* Check if the device in the group still has a driver bound to it */ device_lock(dev); - if (device_is_bound(dev)) { + if (device_is_bound(dev) && !(req_type == IOMMU_DOMAIN_DMA_FQ && + group->default_domain->type == IOMMU_DOMAIN_DMA)) { pr_err_ratelimited("Device is still bound to driver\n"); ret = -EBUSY; goto out;
Allocating and enabling a flush queue is in fact something we can reasonably do while a DMA domain is active, without having to rebuild it from scratch. Thus we can allow a strict -> non-strict transition from sysfs without requiring to unbind the device's driver, which is of particular interest to users who want to make selective relaxations to critical devices like the one serving their root filesystem. Disabling and draining a queue also seems technically possible to achieve without rebuilding the whole domain, but would certainly be more involved. Furthermore there's not such a clear use-case for tightening up security *after* the device may already have done whatever it is that you don't trust it not to do, so we only consider the relaxation case. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/iommu/iommu.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)