mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>, Will Deacon <will@kernel.org>,
	"Jason Gunthorpe" <jgg@nvidia.com>,
	Lu Baolu <baolu.lu@linux.intel.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v1 1/5] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands
Date: Fri, 3 Jul 2026 06:20:37 +0000	[thread overview]
Message-ID: <CO1PR11MB4835A412EADC0D56A8BDBBFC8CF42@CO1PR11MB4835.namprd11.prod.outlook.com> (raw)
In-Reply-To: <eb89a1c564956d9a2ba1d56bd76d57defac205aa.1782767398.git.nicolinc@nvidia.com>

> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, June 30, 2026 5:16 AM
> 
> The arm_vsmmu_cache_invalidate() op hands a guest's invalidation
> commands
> to the trusted main command queue after enforcing only the VMID or the
> SID,
> and passes the rest of the command through to the queue unchanged.
> 
> That lets a guest set bits the host never meant to forward, in two ways. A
> bit can take the command out of the guest's own scope: the ATC_INV Global
> bit, for one, makes the SMMU ignore the SID and invalidate the ATC of every
> device, not just the guest's. A reserved or undefined bit instead makes the
> command malformed; per the Arm SMMUv3 specification, in its section 4.1.3
> "Command errors", a CERROR_ILL is raised, among other cases, when:
> 
>   A valid command opcode is used and a Reserved or undefined field is
>   optionally detected as non-zero, which results in the command being
>   treated as malformed.
> 
> Restrict each opcode to the fields that the driver supports and reject the
> command with -EIO if it sets any other bit, before the command reaches the
> queue. This keeps a guest scoped to its own devices and stops the host from
> forwarding any bit whose meaning it does not control.
> 
> Some fields and whole opcodes are legal only on an SMMU that implements
> the
> matching feature, so accept them conditionally. The NUM, SCALE and TG
> range
> fields need FEAT_RANGE_INV. The ATC_INV opcode needs FEAT_ATS. Per the
> same
> specification's section 4.5 "ATS and PRI", CMD_ATC_INV is ILLEGAL when:
> 
>   SMMU_IDR0.ATS == 0 and this command is issued on a Non-secure or
> Secure
>   Command queue.
> 
> The SSV and SSID substream fields require a non-zero ssid_bits, so without
> substream support setting them is not illegal but CONSTRAINED
> UNPREDICTABLE,
> which a guest should not be able to provoke.
> 
> Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support
> IOMMU_HWPT_INVALIDATE using a VIOMMU object")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

> +	case CMDQ_OP_ATC_INV:
> +		/*
> +		 * Exclude the Global bit: it makes the SMMU ignore the SID
> and
> +		 * invalidate the ATC of every device, not just the guest's.
> +		 */

I suppose the Global bit in vcmdq is guaranteed by HW to be contained within
the vcmdq, then the SMMU will convert it into multiple INV cmds sent to
devices associated with the vcmdq?

> +		allowed[0] |= CMDQ_ATC_0_SID;
> +		allowed[1] |= CMDQ_ATC_1_SIZE |
> CMDQ_ATC_1_ADDR_MASK;
> +		/* SSV/SSID require substream support */
> +		if (vsmmu->smmu->ssid_bits)
> +			allowed[0] |= CMDQ_0_SSV | CMDQ_ATC_0_SSID;
> +		break;

the latter check of ARM_SMMU_FEAT_ATS could be moved here before
setting any allowed bits for ATC_INV.


  reply	other threads:[~2026-07-03  6:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 21:15 [PATCH v1 0/5] iommufd: Iterate the cache invalidation array in the core Nicolin Chen
2026-06-29 21:15 ` [PATCH v1 1/5] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands Nicolin Chen
2026-07-03  6:20   ` Tian, Kevin [this message]
2026-07-03  8:00     ` Nicolin Chen
2026-07-06 17:16   ` Jason Gunthorpe
2026-07-06 17:46     ` Nicolin Chen
2026-06-29 21:15 ` [PATCH v1 2/5] iommufd: Iterate the cache invalidation array in the core Nicolin Chen
2026-07-03  6:21   ` Tian, Kevin
2026-06-29 21:15 ` [PATCH v1 3/5] iommufd/selftest: Convert cache invalidation mocks to the core array loop Nicolin Chen
2026-07-03  6:22   ` Tian, Kevin
2026-06-29 21:15 ` [PATCH v1 4/5] iommu/arm-smmu-v3-iommufd: Convert cache invalidation " Nicolin Chen
2026-07-03  6:30   ` Tian, Kevin
2026-06-29 21:15 ` [PATCH v1 5/5] iommu/vt-d: Convert nested " Nicolin Chen
2026-07-03  6:31   ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO1PR11MB4835A412EADC0D56A8BDBBFC8CF42@CO1PR11MB4835.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox