lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 Feb 2021 17:28:34 +0000
From:   Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
To:     Robin Murphy <robin.murphy@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
CC:     "joro@...tes.org" <joro@...tes.org>,
        "jean-philippe@...aro.org" <jean-philippe@...aro.org>,
        "will@...nel.org" <will@...nel.org>,
        "Zengtao (B)" <prime.zeng@...ilicon.com>,
        "linuxarm@...neuler.org" <linuxarm@...neuler.org>
Subject: RE: [PATCH v2] iommu: Check dev->iommu in iommu_dev_xxx functions



> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: 12 February 2021 16:45
> To: 'Robin Murphy' <robin.murphy@....com>; linux-kernel@...r.kernel.org;
> iommu@...ts.linux-foundation.org
> Cc: joro@...tes.org; jean-philippe@...aro.org; will@...nel.org; Zengtao (B)
> <prime.zeng@...ilicon.com>; linuxarm@...neuler.org
> Subject: RE: [PATCH v2] iommu: Check dev->iommu in iommu_dev_xxx functions
> 
> 
> 
> > -----Original Message-----
> > From: Robin Murphy [mailto:robin.murphy@....com]
> > Sent: 12 February 2021 16:39
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>;
> > linux-kernel@...r.kernel.org; iommu@...ts.linux-foundation.org
> > Cc: joro@...tes.org; jean-philippe@...aro.org; will@...nel.org; Zengtao (B)
> > <prime.zeng@...ilicon.com>; linuxarm@...neuler.org
> > Subject: Re: [PATCH v2] iommu: Check dev->iommu in iommu_dev_xxx
> functions
> >
> > On 2021-02-12 14:54, Shameerali Kolothum Thodi wrote:
> > > Hi Robin/Joerg,
> > >
> > >> -----Original Message-----
> > >> From: Shameer Kolothum
> [mailto:shameerali.kolothum.thodi@...wei.com]
> > >> Sent: 01 February 2021 12:41
> > >> To: linux-kernel@...r.kernel.org; iommu@...ts.linux-foundation.org
> > >> Cc: joro@...tes.org; robin.murphy@....com; jean-philippe@...aro.org;
> > >> will@...nel.org; Zengtao (B) <prime.zeng@...ilicon.com>;
> > >> linuxarm@...neuler.org
> > >> Subject: [Linuxarm] [PATCH v2] iommu: Check dev->iommu in
> > iommu_dev_xxx
> > >> functions
> > >>
> > >> The device iommu probe/attach might have failed leaving dev->iommu
> > >> to NULL and device drivers may still invoke these functions resulting
> > >> in a crash in iommu vendor driver code. Hence make sure we check that.
> > >>
> > >> Also added iommu_ops to the "struct dev_iommu" and set it if the dev
> > >> is successfully associated with an iommu.
> > >>
> > >> Fixes: a3a195929d40 ("iommu: Add APIs for multiple domains per
> device")
> > >> Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi@...wei.com>
> > >> ---
> > >> v1 --> v2:
> > >>   -Added iommu_ops to struct dev_iommu based on the discussion with
> > Robin.
> > >>   -Rebased against iommu-tree core branch.
> > >
> > > A gentle ping on this...
> >
> > Is there a convincing justification for maintaining yet another copy of
> > the ops pointer rather than simply dereferencing iommu_dev->ops at point
> > of use?
> >
> 
> TBH, nothing I can think of now. That was mainly the way I interpreted your
> suggestion
> from the v1.  Now it looks like you didn’t mean it :). I am Ok to rework it to
> dereference
> it from iommu_dev. Please let me know.

So we can do something like this,

index fd76e2f579fe..5fd31a3cec18 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2865,10 +2865,12 @@ EXPORT_SYMBOL_GPL(iommu_fwspec_add_ids);
  */
 int iommu_dev_enable_feature(struct device *dev, enum iommu_dev_features feat)
 {
-       const struct iommu_ops *ops = dev->bus->iommu_ops;
+       if (dev->iommu && dev->iommu->iommu_dev && dev->iommu->iommu_dev->ops)
+               struct iommu_ops  *ops = dev->iommu->iommu_dev->ops;
 
-       if (ops && ops->dev_enable_feat)
-               return ops->dev_enable_feat(dev, feat);
+               if (ops->dev_enable_feat)
+                       return ops->dev_enable_feat(dev, feat);
+       }
 
        return -ENODEV;
 }

Again, not sure we need to do the checking for iommu->dev and ops here. If the
dev->iommu is set, is it safe to assume that we have a valid iommu->iommu_dev
and ops always? (May be it is safer to do the checking in case something
else breaks this assumption in future). Please let me know your thoughts.

Thanks,
Shameer


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ