linux-kernel - Re: [PATCH 7/8] remoteproc: qcom: Add support for memory sandbox

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:   Tue, 9 Aug 2022 12:04:35 +0530
From:   Srinivasa Rao Mandadapu <quic_srivasam@...cinc.com>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
CC:     <agross@...nel.org>, <bgoswami@...cinc.com>,
        <bjorn.andersson@...aro.org>, <broonie@...nel.org>,
        <devicetree@...r.kernel.org>, <judyhsiao@...omium.org>,
        <lgirdwood@...il.com>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-remoteproc@...r.kernel.org>,
        <perex@...ex.cz>, <quic_plai@...cinc.com>,
        <quic_rohkumar@...cinc.com>, <robh+dt@...nel.org>,
        <srinivas.kandagatla@...aro.org>, <swboyd@...omium.org>,
        <tiwai@...e.com>
Subject: Re: [PATCH 7/8] remoteproc: qcom: Add support for memory sandbox


On 8/7/2022 2:09 AM, Christophe JAILLET wrote:
Thanks for Your Time CJ!!!
> Hi,
>
> the error handling below looks odd.
>
> Le 03/08/2022 à 16:21, Srinivasa Rao Mandadapu a écrit :
>> Add memory sandbox support for ADSP based platforms secure booting.
>>
>> Signed-off-by: Srinivasa Rao Mandadapu 
>> <quic_srivasam-jfJNa2p1gH1BDgjK7y7TUQ@...lic.gmane.org>
>> ---
>>   drivers/remoteproc/qcom_q6v5_adsp.c | 101 
>> +++++++++++++++++++++++++++++++++++-
>>   1 file changed, 99 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c 
>> b/drivers/remoteproc/qcom_q6v5_adsp.c
>> index 3dbd035..f81da47 100644
>> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
>> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
>
>>   static int adsp_start(struct rproc *rproc)
>>   {
>>       struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
>> @@ -341,7 +429,13 @@ static int adsp_start(struct rproc *rproc)
>>       ret = qcom_q6v5_prepare(&adsp->q6v5);
>>       if (ret)
>>           return ret;
>> -
>> +    if (!adsp->is_wpss) {
>> +        ret = adsp_map_smmu(adsp, rproc);
>> +        if (ret) {
>> +            dev_err(adsp->dev, "ADSP smmu mapping failed\n");
>> +            goto adsp_smmu_unmap;
> goto disable_irqs;?
Yes. will correct it accordingly.
>
>> +        }
>> +    }
>>       ret = clk_prepare_enable(adsp->xo);
>>       if (ret)
>>           goto disable_irqs;
>
> goto adsp_smmu_unmap;?
Yes. will correct it accordingly.
>
>> @@ -402,6 +496,9 @@ static int adsp_start(struct rproc *rproc)
>>       clk_disable_unprepare(adsp->xo);
>>   disable_irqs:
>>       qcom_q6v5_unprepare(&adsp->q6v5);
>> +adsp_smmu_unmap:
>> +    iommu_unmap(adsp->iommu_dom, adsp->mem_phys, adsp->mem_size);
>> +    iommu_domain_free(adsp->iommu_dom);
>
> Should this new hunk be above disable_irqs?
> And I think that it should be guardd with a "if (!adsp->is_wpss)".
Yes. will correct it accordingly.
>
> CJ
>
>>         return ret;
>>   }
>