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 15:33:42 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Nicolin Chen <nicolinc@...dia.com>, 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
Cc:     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

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.

> 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 :/

[...]
> 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.

Thanks,
Robin.

> +		return -EMEDIUMTYPE;
> +
>   	if (unlikely(domain->ops->attach_dev == NULL))
>   		return -ENODEV;