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]
Date:   Mon, 6 Jun 2022 00:06:18 +0200
From:   Marijn Suijten <marijn.suijten@...ainline.org>
To:     Will Deacon <will@...nel.org>
Cc:     Konrad Dybcio <konrad.dybcio@...ainline.org>,
        ~postmarketos/upstreaming@...ts.sr.ht,
        linux-arm-msm@...r.kernel.org, bjorn.andersson@...aro.org,
        linux-arm-kernel@...ts.infradead.org,
        iommu@...ts.linux-foundation.org, martin.botka@...ainline.org,
        angelogioacchino.delregno@...ainline.org,
        jamipkettunen@...ainline.org, Rob Clark <robdclark@...il.com>,
        Robin Murphy <robin.murphy@....com>,
        Joerg Roedel <joro@...tes.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] iommu/qcom: Write TCR before TTBRs to fix ASID
 access behavior

On 2022-05-31 16:55:59, Will Deacon wrote:
> On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote:
> > From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...ainline.org>
> > 
> > As also stated in the arm-smmu driver, we must write the TCR before
> > writing the TTBRs, since the TCR determines the access behavior of
> > some fields.
> 
> Where is this stated in the arm-smmu driver?
> 
> > 
> > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...ainline.org>
> > Signed-off-by: Marijn Suijten <marijn.suijten@...ainline.org>
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@...ainline.org>
> > ---
> >  drivers/iommu/arm/arm-smmu/qcom_iommu.c | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> > index 1728d4d7fe25..75f353866c40 100644
> > --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> > +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
> > @@ -273,18 +273,18 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
> >  			ctx->secure_init = true;
> >  		}
> >  
> > -		/* TTBRs */
> > -		iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
> > -				pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
> > -				FIELD_PREP(ARM_SMMU_TTBRn_ASID, ctx->asid));
> > -		iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0);
> > -
> >  		/* TCR */
> >  		iommu_writel(ctx, ARM_SMMU_CB_TCR2,
> >  				arm_smmu_lpae_tcr2(&pgtbl_cfg));
> >  		iommu_writel(ctx, ARM_SMMU_CB_TCR,
> >  			     arm_smmu_lpae_tcr(&pgtbl_cfg) | ARM_SMMU_TCR_EAE);
> >  
> > +		/* TTBRs */
> > +		iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
> > +				pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
> > +				FIELD_PREP(ARM_SMMU_TTBRn_ASID, ctx->asid));
> > +		iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0);
> 
> I'd have thought that SCTLR.M would be clear here, so it shouldn't matter
> what order we write these in.

Having tested the series without this particular patch on 8976 (Sony
Loire Suzu), it doesn't seem to matter indeed.  I'll ask around if this
"access behaviour" was observed on a different board/platform.

- Marijn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ