linux-kernel - Re: [PATCH v3] iommu/arm-smmu-qcom: Rework the logic finding the bypass quirk

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: <20230315075958.GC25575@thinkpad>
Date:   Wed, 15 Mar 2023 13:29:58 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     will@...nel.org, joro@...tes.org, robin.murphy@....com,
        andersson@...nel.org, johan+linaro@...nel.org, steev@...i.org,
        linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] iommu/arm-smmu-qcom: Rework the logic finding the
 bypass quirk

On Wed, Mar 15, 2023 at 08:37:32AM +0100, Johan Hovold wrote:
> On Wed, Mar 15, 2023 at 12:16:59AM +0530, Manivannan Sadhasivam wrote:
> > The logic used to find the quirky firmware that intercepts the writes to
> > S2CR register to replace bypass type streams with a fault, and ignore the
> > fault type, is not working with the firmware on newer SoCs like SC8280XP.
> > 
> > The current logic uses the last stream mapping group (num_mapping_groups
> > - 1) as an index for finding quirky firmware. But on SC8280XP, NUMSMRG
> > reports a value of 162 due to emulation and the logic is not working for
> > stream mapping groups > 128. (Note that the ARM SMMU architecture
> > specification defines NUMSMRG in the range of 0-127).
> > 
> > So the current logic that checks the (162-1)th S2CR entry fails to detect
> > the quirky firmware on these devices and SMMU triggers invalid context
> > fault for bypass streams.
> > 
> > To fix this issue, let's limit "num_mapping_groups" to 128 as per ARM SMMU
> > spec and rework the logic to find the first non-valid (free) stream mapping
> > register group (SMR) and use that index to access S2CR for detecting the
> > bypass quirk. If no free groups are available, then just skip the quirk
> > detection.
> > 
> > While at it, let's move the quirk detection logic to a separate function
> > and change the local variable name from last_s2cr to free_s2cr.
> > 
> > Reviewed-by: Bjorn Andersson <andersson@...nel.org>
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > ---
> > 
> > Changes in v3:
> > 
> > * Limited num_mapping_groups to 128 as per ARM SMMU spec and removed the
> >   check for 128 groups in qcom_smmu_bypass_quirk()
> > * Reworded the commit message accordingly
> > 
> > Changes in v2:
> > 
> > * Limited the check to 128 groups as per ARM SMMU spec's NUMSMRG range
> > * Moved the quirk handling to its own function
> > * Collected review tag from Bjorn
> 
> > +static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
> > +{
> > +	u32 smr;
> > +	int i;
> > +
> > +	/*
> > +	 * Limit the number of stream matching groups to 128 as the ARM SMMU architecture
> > +	 * specification defines NUMSMRG (Number of Stream Mapping Register Groups) in the
> > +	 * range of 0-127, but some Qcom platforms emulate more stream mapping groups. And
> > +	 * those groups don't exhibit the same behavior as the architecture supported ones.
> > +	 */
> 
> Please fix your editor so that it wraps lines at 80 columns, which is
> still the preferred (soft) limit.
> 

If exceeding 80 columns end up making the comment more readable (fewer lines),
then why should we limit ourselves?

> > +	if (smmu->num_mapping_groups > 128) {
> > +		dev_warn(smmu->dev, "\tLimiting the stream matching groups to 128\n");
> 
> dev_notice() should do since there's nothing a user can do about this.
> 

Ok.

> > +		smmu->num_mapping_groups = 128;
> > +	}
> 
> So this hunk is really all that is needed to make the current quirk
> detection work on sc8280xp. Why not simply stick with the current logic
> and use the last group until there is a need for anything more?
> 

No! What if the bootloader had set up mapping for 128 groups? In that case
we'll overwrite the last group. It is still required to find the valid group
and use it for quirk detection. If no group is available, we'll skip it.

> Also, should this not be done in arm_smmu_device_cfg_probe() as I
> suggested earlier (e.g. to avoid allocating resources for the groups
> that will never be used)?
> 

I just went with Robin's suggestion on adding this check to cfg_probe() hook.
But I don't have any strong preference either.

Thanks,
Mani

> > +
> > +	qcom_smmu_bypass_quirk(smmu);
> >  
> >  	for (i = 0; i < smmu->num_mapping_groups; i++) {
> >  		smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
> 
> Johan

-- 
மணிவண்ணன் சதாசிவம்