linux-kernel - Re: [PATCH v1 03/20] iommu/arm-smmu-v3: Implement arm_smmu_domain_test

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]

Message-ID: <20251020163231.GX316284@nvidia.com>
Date: Mon, 20 Oct 2025 13:32:31 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: joro@...tes.org, kevin.tian@...el.com, suravee.suthikulpanit@....com,
	will@...nel.org, robin.murphy@....com, sven@...nel.org,
	j@...nau.net, jean-philippe@...aro.org,
	robin.clark@....qualcomm.com, dwmw2@...radead.org,
	baolu.lu@...ux.intel.com, yong.wu@...iatek.com,
	matthias.bgg@...il.com, angelogioacchino.delregno@...labora.com,
	tjeznach@...osinc.com, pjw@...nel.org, palmer@...belt.com,
	aou@...s.berkeley.edu, heiko@...ech.de, schnelle@...ux.ibm.com,
	mjrosato@...ux.ibm.com, wens@...e.org, jernej.skrabec@...il.com,
	samuel@...lland.org, thierry.reding@...il.com, jonathanh@...dia.com,
	iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org, linux-mediatek@...ts.infradead.org,
	linux-riscv@...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.dev,
	patches@...ts.linux.dev
Subject: Re: [PATCH v1 03/20] iommu/arm-smmu-v3: Implement
 arm_smmu_domain_test_dev

On Sun, Oct 12, 2025 at 05:05:00PM -0700, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index a33fbd12a0dd9..3448e55bbcdbb 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2765,9 +2765,6 @@ static int arm_smmu_enable_iopf(struct arm_smmu_master *master,
>  
>  	iommu_group_mutex_assert(master->dev);
>  
> -	if (!IS_ENABLED(CONFIG_ARM_SMMU_V3_SVA))
> -		return -EOPNOTSUPP;

Stuff like this is also optimizing the codegen, it shouldn't be
removed.

> +int arm_smmu_domain_test_dev(struct iommu_domain *domain, struct device *dev,
> +			     ioasid_t pasid, struct iommu_domain *old_domain)
> +{
> +	struct arm_smmu_domain *device_domain = to_smmu_domain_devices(domain);
> +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> +
> +	if (!dev_iommu_fwspec_get(dev))
> +		return -ENOENT;
> +
> +	switch (domain->type) {
> +	case IOMMU_DOMAIN_NESTED: {
> +		struct arm_smmu_nested_domain *nested_domain =
> +			to_smmu_nested_domain(domain);
> +
> +		if (WARN_ON(pasid != IOMMU_NO_PASID))
> +			return -EOPNOTSUPP;
> +		if (nested_domain->vsmmu->smmu != master->smmu)
> +			return -EINVAL;
> +		if (arm_smmu_ssids_in_use(&master->cd_table))
> +			return -EBUSY;

This gives me alot of pause.. Here we are detecting if a S1 PASID is
installed for a S2 attach, but to your purpose this can be made
inconsistent by userspace during a FLR..

I don't see any reasonable way to mitigate this??

Which makes me wonder if we should just try to solve the simple
obvious things like direct, permanent incompatability and still have
some kind of recovery code to leave things in blocking if they fail to
attach

Jason