From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Will Deacon <will@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
Kevin Tian <kevin.tian@intel.com>,
Robin Murphy <robin.murphy@arm.com>,
joro@8bytes.org, David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/6] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands
Date: Wed, 15 Jul 2026 19:54:21 +0000 [thread overview]
Message-ID: <alflbbClvEp_k6u-@google.com> (raw)
In-Reply-To: <5c70a336821e3cea176356470d94ff18329ff867.1784054606.git.nicolinc@nvidia.com>
On Tue, Jul 14, 2026 at 11:48:48AM -0700, Nicolin Chen wrote:
> 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.
>
[...]
> +
> +static int arm_vsmmu_validate_user_cmd(struct arm_vsmmu *vsmmu, u64 data[2])
> +{
> + struct arm_smmu_device *smmu = vsmmu->smmu;
> + u64 allowed[2] = { CMDQ_0_OP };
> +
> + /* Collect the fields userspace is allowed to set for each opcode */
> + switch (data[0] & CMDQ_0_OP) {
> + case CMDQ_OP_TLBI_NH_VA:
> + /* An SMMU with 8-bit ASIDs treats the upper 8 bits as RES0 */
> + allowed[0] |= FIELD_PREP(CMDQ_TLBI_0_ASID,
> + GENMASK(smmu->asid_bits - 1, 0));
> + fallthrough;
> + case CMDQ_OP_TLBI_NH_VAA:
> + /* NUM/SCALE/TG/TTL are range fields gated on FEAT_RANGE_INV */
> + if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
> + if (arm_vsmmu_validate_range(smmu, data))
> + return -EIO;
> + allowed[0] |= CMDQ_TLBI_0_NUM | CMDQ_TLBI_0_SCALE;
> + allowed[1] |= CMDQ_TLBI_1_TG | CMDQ_TLBI_1_TTL;
> + /* SCALE bit 25 (values above 31) is RES0 without DS */
> + if (!(smmu->features & ARM_SMMU_FEAT_DS))
> + allowed[0] &= ~FIELD_PREP(CMDQ_TLBI_0_SCALE,
> + BIT(5));
> + }
> + allowed[0] |= CMDQ_TLBI_0_VMID;
> + allowed[1] |= CMDQ_TLBI_1_LEAF | CMDQ_TLBI_1_VA_MASK;
> + break;
> + case CMDQ_OP_TLBI_NH_ASID:
> + /* An SMMU with 8-bit ASIDs treats the upper 8 bits as RES0 */
> + allowed[0] |= FIELD_PREP(CMDQ_TLBI_0_ASID,
> + GENMASK(smmu->asid_bits - 1, 0));
> + fallthrough;
> + case CMDQ_OP_TLBI_NH_ALL:
> + allowed[0] |= CMDQ_TLBI_0_VMID;
> + break;
> + case CMDQ_OP_ATC_INV:
> + /* ATC_INV is illegal unless the SMMU implements ATS */
> + if (!(smmu->features & ARM_SMMU_FEAT_ATS))
> + return -EIO;
> + /* A Size above 52 (invalidate-all) may raise a CERROR_ILL */
> + if (FIELD_GET(CMDQ_ATC_1_SIZE, data[1]) > ATC_INV_SIZE_ALL)
> + return -EIO;
> + /*
> + * SSV/SSID/Global need substream support. SSID and Global are
> + * IGNORED (not RES0) when SSV == 0, so they need no SSV check.
> + */
> + if (smmu->ssid_bits)
> + allowed[0] |= CMDQ_0_SSV | CMDQ_ATC_0_SSID |
> + CMDQ_ATC_0_GLOBAL;
> + allowed[0] |= CMDQ_ATC_0_SID;
> + allowed[1] |= CMDQ_ATC_1_SIZE | CMDQ_ATC_1_ADDR_MASK;
> + break;
> + case CMDQ_OP_CFGI_CD:
> + /* No SSV for CFGI_CD; SSID requires substream support */
> + if (smmu->ssid_bits)
> + allowed[0] |= CMDQ_CFGI_0_SSID;
> + allowed[1] |= CMDQ_CFGI_1_LEAF;
> + fallthrough;
> + case CMDQ_OP_CFGI_CD_ALL:
> + allowed[0] |= CMDQ_CFGI_0_SID;
> + break;
Nit: Although, the convert_user_cmd would check the CMDQ_OP again, it
seems like validate_user_cmd would return 0 for an unsupported cmd that
doesn't match any of the above cases, should we add a default case and
return -EIO there?
> + }
> +
> + /*
> + * Reject any other bit, e.g. a RES0 bit or a Secure bit, before the
> + * command reaches the trusted main cmdq, so a guest cannot wedge the
> + * shared queue for every device with a CERROR_ILL.
> + *
> + * By contrast, an out-of-range address or ID value does not need a
> + * check: the spec defines it as CONSTRAINED UNPREDICTABLE, which is
> + * scoped to the guest itself and does not raise a CERROR_ILL.
> + */
> + if ((data[0] & ~allowed[0]) || (data[1] & ~allowed[1]))
> + return -EIO;
> + return 0;
> +}
> +
Apart from that,
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
next prev parent reply other threads:[~2026-07-15 19:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 18:48 [PATCH v4 0/6] iommufd: Iterate the cache invalidation array in the core Nicolin Chen
2026-07-14 18:48 ` [PATCH v4 1/6] iommu/arm-smmu-v3: Support IDR5.DS and widen the TLBI SCALE field Nicolin Chen
2026-07-15 18:58 ` Jason Gunthorpe
2026-07-15 19:41 ` Pranjal Shrivastava
2026-07-15 20:00 ` Jason Gunthorpe
2026-07-14 18:48 ` [PATCH v4 2/6] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands Nicolin Chen
2026-07-15 19:00 ` Jason Gunthorpe
2026-07-15 19:54 ` Pranjal Shrivastava [this message]
2026-07-14 18:48 ` [PATCH v4 3/6] iommufd: Iterate the cache invalidation array in the core Nicolin Chen
2026-07-15 20:03 ` Jason Gunthorpe
2026-07-14 18:48 ` [PATCH v4 4/6] iommufd/selftest: Convert cache invalidation mocks to the core array loop Nicolin Chen
2026-07-14 18:48 ` [PATCH v4 5/6] iommu/arm-smmu-v3-iommufd: Convert cache invalidation " Nicolin Chen
2026-07-15 20:05 ` Jason Gunthorpe
2026-07-14 18:48 ` [PATCH v4 6/6] iommu/vt-d: Convert nested " Nicolin Chen
2026-07-15 20:15 ` [PATCH v4 0/6] iommufd: Iterate the cache invalidation array in the core Jason Gunthorpe
2026-07-15 20:30 ` Nicolin Chen
2026-07-16 15:18 ` Jason Gunthorpe
2026-07-16 16:20 ` Nicolin Chen
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=alflbbClvEp_k6u-@google.com \
--to=praan@google.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=kevin.tian@intel.com \
--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