linux-kernel - Re: [PATCH 8/8] dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees

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: <a967c354-cb33-402a-8be5-2a89a5108946@oss.qualcomm.com>
Date: Wed, 12 Feb 2025 23:19:10 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Stephan Gerhold <stephan.gerhold@...aro.org>,
        Vinod Koul <vkoul@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, Andy Gross <agross@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Yuvaraj Ranganathan <quic_yrangana@...cinc.com>,
        Anusha Rao <quic_anusha@...cinc.com>,
        Md Sadre Alam
 <quic_mdalam@...cinc.com>,
        linux-arm-msm@...r.kernel.org, dmaengine@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Luca Weiss <luca.weiss@...rphone.com>
Subject: Re: [PATCH 8/8] dmaengine: qcom: bam_dma: Fix DT error handling for
 num-channels/ees

On 12.02.2025 6:03 PM, Stephan Gerhold wrote:
> When we don't have a clock specified in the device tree, we have no way to
> ensure the BAM is on. This is often the case for remotely-controlled or
> remotely-powered BAM instances. In this case, we need to read num-channels
> from the DT to have all the necessary information to complete probing.
> 
> However, at the moment invalid device trees without clock and without
> num-channels still continue probing, because the error handling is missing
> return statements. The driver will then later try to read the number of
> channels from the registers. This is unsafe, because it relies on boot
> firmware and lucky timing to succeed. Unfortunately, the lack of proper
> error handling here has been abused for several Qualcomm SoCs upstream,
> causing early boot crashes in several situations [1, 2].
> 
> Avoid these early crashes by erroring out when any of the required DT
> properties are missing. Note that this will break some of the existing DTs
> upstream (mainly BAM instances related to the crypto engine). However,
> clearly these DTs have never been tested properly, since the error in the
> kernel log was just ignored. It's safer to disable the crypto engine for
> these broken DTBs.
> 
> [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
> [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
> 
> Cc: stable@...r.kernel.org
> Fixes: 48d163b1aa6e ("dmaengine: qcom: bam_dma: get num-channels and num-ees from dt")
> Signed-off-by: Stephan Gerhold <stephan.gerhold@...aro.org>
> ---
>  drivers/dma/qcom/bam_dma.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index c14557efd577046adc74fa83fd45eb239977b5fa..a2f1f8902c7f88398a5412e8673e24b3c10bb86f 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1291,13 +1291,17 @@ static int bam_dma_probe(struct platform_device *pdev)
>  	if (!bdev->bamclk) {
>  		ret = of_property_read_u32(pdev->dev.of_node, "num-channels",
>  					   &bdev->num_channels);
> -		if (ret)
> +		if (ret) {
>  			dev_err(bdev->dev, "num-channels unspecified in dt\n");
> +			return ret;
> +		}
>  
>  		ret = of_property_read_u32(pdev->dev.of_node, "qcom,num-ees",
>  					   &bdev->num_ees);
> -		if (ret)
> +		if (ret) {
>  			dev_err(bdev->dev, "num-ees unspecified in dt\n");
> +			return ret;
> +		}

I like dev_err_probe, but this works too

Reviewed-by: Konrad Dybcio <konrad.dybcio@....qualcomm.com>

Konrad