linux-kernel - Re: [PATCH 8/8] iommu/arm-smmu-qcom: Add stream_mapping

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20201014221440.GA299663@builder.lan>
Date:   Wed, 14 Oct 2020 17:14:40 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     kholk11@...il.com
Cc:     will@...nel.org, robin.murphy@....com, joro@...tes.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        marijns95@...il.com, konradybcio@...il.com,
        martin.botka1@...il.com, linux-arm-msm@...r.kernel.org,
        phone-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 8/8] iommu/arm-smmu-qcom: Add stream_mapping_reset detail
 to QCOM SMMUv2

On Sat 26 Sep 08:00 CDT 2020, kholk11@...il.com wrote:

> From: AngeloGioacchino Del Regno <kholk11@...il.com>
> 
> On some Qualcomm SoCs with certain hypervisor configurations,
> some context banks are hyp-protected and cannot be disabled,
> nor the relative S2CRs can be set as bypass, or a hyp-fault
> will be triggered and the system will hang.
> 
> This is seen on at least Qualcomm SDM630, SDM636 and SDM660.
> 
> Signed-off-by: AngeloGioacchino Del Regno <kholk11@...il.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index b18e70bddf29..364908cc2adf 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -85,6 +85,18 @@ static int qcom_smmuv2_cfg_probe(struct arm_smmu_device *smmu)
>  	return 0;
>  }
>  
> +static void qcom_smmuv2_stream_mapping_reset(struct arm_smmu_device *smmu)
> +{
> +	/*
> +	 * Broken firmware quirk:
> +	 * On some Qualcomm SoCs with certain hypervisor configurations,
> +	 * some context banks are hyp-protected and cannot be disabled,

Wouldn't you run into the same problem when init_domain_context() later
comes along and "accidentally" pick one of these context banks?

Do we have any way of knowing which banks this is, so we can mark them
as busy?

> +	 * nor the relative S2CRs can be set as bypass, or a hyp-fault

On platforms such as SDM845, SM8150, SM8250 etc, writing S2CR of type
BYPASS is trapped by the hypervisor and FAULT is actually written to the
hardware - resulting in a system reset when the associated hardware
tries to perform a memory access.


Is it the actual S2CR write that causes the problem you're seeing or the
fact that it happens to be that you shoot down the display stream as
soon as you touch these registers?

Regards,
Bjorn

> +	 * will be triggered and the system will hang.
> +	 */
> +	return;
> +}
> +
>  static void qcom_smmuv2_test_smr_masks(struct arm_smmu_device *smmu)
>  {
>  	/*
> @@ -99,6 +111,7 @@ static void qcom_smmuv2_test_smr_masks(struct arm_smmu_device *smmu)
>  
>  static const struct arm_smmu_impl qcom_smmuv2_impl = {
>  	.cfg_probe = qcom_smmuv2_cfg_probe,
> +	.stream_mapping_reset = qcom_smmuv2_stream_mapping_reset,
>  	.test_smr_masks = qcom_smmuv2_test_smr_masks,
>  };
>  
> -- 
> 2.28.0
>