linux-kernel - Re: [PATCH] firmware: qcom_scm: use the SCM

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: <CAH=2NtydsLsTRhWEqocg4AQPzk5QURHeKNe7N-DhhV2-qnic6Q@mail.gmail.com>
Date:   Mon, 22 May 2023 12:03:58 +0530
From:   Bhupesh Sharma <bhupesh.sharma@...aro.org>
To:     Kathiravan T <quic_kathirav@...cinc.com>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        quic_eberman@...cinc.com
Subject: Re: [PATCH] firmware: qcom_scm: use the SCM_CONVENTION based on ARM / ARM64

Hi,

On Mon, 22 May 2023 at 10:15, Kathiravan T <quic_kathirav@...cinc.com> wrote:
>
> During SCM probe, to identify the SCM convention, scm call is made with
> SMC_CONVENTION_ARM_64 followed by SMC_CONVENTION_ARM_32. Based on the
> result what convention to be used is decided.
>
> IPQ chipsets starting from IPQ807x, supports both 32bit and 64bit kernel
> variants, however TZ firmware runs in 64bit mode. When running on 32bit
> kernel, scm call is made with SMC_CONVENTION_ARM_64 is causing the
> system crash, due to the difference in the register sets between ARM and
> AARCH64, which is accessed by the TZ.

If a crash is being fixed, should we use a Fixes tag as well?

> To avoid this, use SMC_CONVENTION_ARM_64 only on ARM64 builds.
>
> Signed-off-by: Kathiravan T <quic_kathirav@...cinc.com>
> ---
>  drivers/firmware/qcom_scm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index fde33acd46b7..db6754db48a0 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -171,6 +171,7 @@ static enum qcom_scm_convention __get_convention(void)
>         if (likely(qcom_scm_convention != SMC_CONVENTION_UNKNOWN))
>                 return qcom_scm_convention;
>
> +#if IS_ENABLED(CONFIG_ARM64)
>         /*
>          * Device isn't required as there is only one argument - no device
>          * needed to dma_map_single to secure world
> @@ -191,6 +192,7 @@ static enum qcom_scm_convention __get_convention(void)
>                 forced = true;
>                 goto found;
>         }
> +#endif

If we are already inside a 'CONFIG_ARM64' define here ^^^, do we even
need the following snippet now:

/*
     * Some SC7180 firmwares didn't implement the
     * QCOM_SCM_INFO_IS_CALL_AVAIL call, so we fallback to forcing ARM_64
     * calling conventions on these firmwares. Luckily we don't make any
     * early calls into the firmware on these SoCs so the device pointer
     * will be valid here to check if the compatible matches.
     */
    if (of_device_is_compatible(__scm ? __scm->dev->of_node : NULL,
"qcom,scm-sc7180")) {
        forced = true;
        goto found;
    }

'forced' will always be 'true' now that we are inside the CONFIG_ARM64
check above, right?
So, maybe you can clean-up that path as well.

Thanks,
Bhupesh