linux-kernel - Re: [PATCH] iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal

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: <aMAkJ7CfPQuhvhfm@willie-the-truck>
Date: Tue, 9 Sep 2025 13:57:11 +0100
From: Will Deacon <will@...nel.org>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: Robin Murphy <robin.murphy@....com>, Joerg Roedel <joro@...tes.org>,
	Rob Clark <robin.clark@....qualcomm.com>,
	Manivannan Sadhasivam <mani@...nel.org>,
	Johan Hovold <johan@...nel.org>,
	Bjorn Andersson <andersson@...nel.org>, iommu@...ts.linux.dev,
	linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu-qcom: Enable use of all SMR groups when
 running bare-metal

On Thu, Aug 21, 2025 at 10:33:53AM +0200, Stephan Gerhold wrote:
> Some platforms (e.g. SC8280XP and X1E) support more than 128 stream
> matching groups. This is more than what is defined as maximum by the ARM
> SMMU architecture specification. Commit 122611347326 ("iommu/arm-smmu-qcom:
> Limit the SMR groups to 128") disabled use of the additional groups because
> they don't exhibit the same behavior as the architecture supported ones.
> 
> It seems like this is just another quirk of the hypervisor: When running
> bare-metal without the hypervisor, the additional groups appear to behave
> just like all others. The boot firmware uses some of the additional groups,
> so ignoring them in this situation leads to stream match conflicts whenever
> we allocate a new SMR group for the same SID.
> 
> The workaround exists primarily because the bypass quirk detection fails
> when using a S2CR register from the additional matching groups, so let's
> perform the test with the last reliable S2CR (127) and then limit the
> number of SMR groups only if we detect that we are running below the
> hypervisor (because of the bypass quirk).
> 
> Fixes: 122611347326 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@...aro.org>
> ---
> I modified arm_smmu_find_sme() to prefer allocating from the SMR groups
> above 128 (until they are all used). I did not see any issues, so I don't
> see any indication that they behave any different from the others.
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 27 +++++++++++++++++----------
>  1 file changed, 17 insertions(+), 10 deletions(-)

Is the existing workaround causing you problems somehow? Limiting the SMR
groups to what the architecture allows still seems like the best bet to
me unless there's a compelling reason to do something else.

Will