From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Will Deacon <will@kernel.org>, 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,
Pranjal Shrivastava <praan@google.com>
Subject: Re: [PATCH v4 2/6] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands
Date: Wed, 15 Jul 2026 16:00:51 -0300 [thread overview]
Message-ID: <20260715190051.GH3775915@nvidia.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.
>
> That lets a guest set bits the host never meant to forward: a reserved or
> undefined bit makes a 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 stops the host from forwarding any bit whose meaning it does
> not control. Document this contract in the uAPI header, so user space must
> take the responsibility to forward valid commands only.
>
> Some fields and whole opcodes are legal only on an SMMU that implements
> the matching feature, so accept them conditionally:
>
> - NUM, SCALE, TG and TTL need FEAT_RANGE_INV.
> - SCALE bit 25, for values above 31, and TTL == 0b01 with a 16KB TG
> need SMMU_IDR5.DS, gated on ARM_SMMU_FEAT_DS so that a VMM exposing
> DS from the reported IDR5 register keeps working.
> - ASID is limited to asid_bits, since its upper 8 bits are RES0 on an
> SMMU that only supports 8-bit ASIDs.
> - ATC_INV needs FEAT_ATS. Per the 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.
>
> - SSV, SSID and Global need a non-zero ssid_bits. Without it, setting
> them is not illegal but CONSTRAINED UNPREDICTABLE, which a guest
> should not be able to provoke. Global also takes effect only when
> SSV == 1, broadening the invalidation from the one SSID to all the
> PASIDs of the single device that the SID field addresses.
>
> Some values inside the accepted fields are Reserved too:
>
> - NUM == 0, SCALE == 0 and TTL == 0 together are a Reserved combination
> and cause a CERROR_ILL.
> - NUM, SCALE and TTL turn RES0 when TG == 0.
> - An ATC_INV Size above 52, the invalidate-all span, is permitted to
> raise a CERROR_ILL.
>
> Reject these Reserved values the same way. In contrast, an out-of-range
> address or ID value is defined as CONSTRAINED UNPREDICTABLE that would
> be scoped to the guest itself, so it does not deserve a check.
>
> Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/uapi/linux/iommufd.h | 4 +-
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 125 ++++++++++++++++--
> 2 files changed, 117 insertions(+), 12 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
next prev parent reply other threads:[~2026-07-15 19:00 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 [this message]
2026-07-15 19:54 ` Pranjal Shrivastava
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=20260715190051.GH3775915@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--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=praan@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.