linux-kernel - Re: [PATCH 2/5] iommu: Ensure device has the same iommu

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:   Mon, 6 Jun 2022 09:51:20 -0700
From:   Nicolin Chen <nicolinc@...dia.com>
To:     Robin Murphy <robin.murphy@....com>
CC:     <jgg@...dia.com>, <joro@...tes.org>, <will@...nel.org>,
        <marcan@...can.st>, <sven@...npeter.dev>, <robdclark@...il.com>,
        <m.szyprowski@...sung.com>, <krzysztof.kozlowski@...aro.org>,
        <baolu.lu@...ux.intel.com>, <agross@...nel.org>,
        <bjorn.andersson@...aro.org>, <matthias.bgg@...il.com>,
        <heiko@...ech.de>, <orsonzhai@...il.com>, <baolin.wang7@...il.com>,
        <zhang.lyra@...il.com>, <wens@...e.org>,
        <jernej.skrabec@...il.com>, <samuel@...lland.org>,
        <jean-philippe@...aro.org>, <alex.williamson@...hat.com>,
        <suravee.suthikulpanit@....com>, <alyssa@...enzweig.io>,
        <alim.akhtar@...sung.com>, <dwmw2@...radead.org>,
        <yong.wu@...iatek.com>, <mjrosato@...ux.ibm.com>,
        <gerald.schaefer@...ux.ibm.com>, <thierry.reding@...il.com>,
        <vdumpa@...dia.com>, <jonathanh@...dia.com>, <cohuck@...hat.com>,
        <iommu@...ts.linux-foundation.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-arm-msm@...r.kernel.org>,
        <linux-samsung-soc@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>,
        <linux-rockchip@...ts.infradead.org>, <linux-s390@...r.kernel.org>,
        <linux-sunxi@...ts.linux.dev>, <linux-tegra@...r.kernel.org>,
        <virtualization@...ts.linux-foundation.org>, <kvm@...r.kernel.org>
Subject: Re: [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the
 domain

Hi Robin,

On Mon, Jun 06, 2022 at 03:33:42PM +0100, Robin Murphy wrote:
> On 2022-06-06 07:19, Nicolin Chen wrote:
> > The core code should not call an iommu driver op with a struct device
> > parameter unless it knows that the dev_iommu_priv_get() for that struct
> > device was setup by the same driver. Otherwise in a mixed driver system
> > the iommu_priv could be casted to the wrong type.
> 
> We don't have mixed-driver systems, and there are plenty more
> significant problems than this one to solve before we can (but thanks
> for pointing it out - I hadn't got as far as auditing the public
> interfaces yet). Once domains are allocated via a particular device's
> IOMMU instance in the first place, there will be ample opportunity for
> the core to stash suitable identifying information in the domain for
> itself. TBH even the current code could do it without needing the
> weirdly invasive changes here.

Do you have an alternative and less invasive solution in mind?

> > Store the iommu_ops pointer in the iommu_domain and use it as a check to
> > validate that the struct device is correct before invoking any domain op
> > that accepts a struct device.
> 
> In fact this even describes exactly that - "Store the iommu_ops pointer
> in the iommu_domain", vs. the "Store the iommu_ops pointer in the
> iommu_domain_ops" which the patch is actually doing :/

Will fix that.

> [...]
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 19cf28d40ebe..8a1f437a51f2 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -1963,6 +1963,10 @@ static int __iommu_attach_device(struct iommu_domain *domain,
> >   {
> >       int ret;
> > 
> > +     /* Ensure the device was probe'd onto the same driver as the domain */
> > +     if (dev->bus->iommu_ops != domain->ops->iommu_ops)
> 
> Nope, dev_iommu_ops(dev) please. Furthermore I think the logical place
> to put this is in iommu_group_do_attach_device(), since that's the
> gateway for the public interfaces - we shouldn't need to second-guess
> ourselves for internal default-domain-related calls.

Will move to iommu_group_do_attach_device and change to dev_iommu_ops.

Thanks!
Nic