Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp5787191rwb; Tue, 9 Aug 2022 04:14:05 -0700 (PDT) X-Google-Smtp-Source: AA6agR5OFSczVQk9z4T9WTJl2jYGKXEcDkzc6Ni1N3FeVXC3HZc+da+X2UAou6qLTEBWt55Dv4G+ X-Received: by 2002:a17:907:2719:b0:730:a688:f1e4 with SMTP id w25-20020a170907271900b00730a688f1e4mr16719855ejk.425.1660043645267; Tue, 09 Aug 2022 04:14:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660043645; cv=none; d=google.com; s=arc-20160816; b=Jk0s9v0liIhlXxXiOq3DacdCKC0h/xTA8SZiKJ+ZSbc4pTm3kAQNxWGi/+zO8fHIud AH60H2kVYZi8HpIUK5F74KcIBtW9Mk11XW3FbQv6MBdU0oNrSXI2JoEgL3IoHhi0xsvZ ZtgjuJv9hYX4fh4SXV0x35LyOeCLkF/In3NRoMPHgx9RBxmnnbzLdfghSjuE6shyQ4He NI6unFkYqR/++ns9MdIlJA0XY4zTE+GBm8rNKTVuJkUEL1Q5+2nBLYE9ZKHyExCIS3tf TPbi4fRaNRIu1/1RWZMn6F2NM8+koyYdd6auQZgsBEWdl3j6B/BU6BQK4QR/QaJYHil/ csSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:references:to:from:content-language:subject:user-agent :mime-version:date:message-id:dkim-signature; bh=oBwBvZSsMZBHlODzJPdCUM/1aMAkHwPlD1L/widFSYM=; b=JNTVpGaS7mTKNvZYygMzqe73dhArkhpR6LKbF354n4peOrNq80VO4XDYjMyW0VdKDP cm7QUbIizF5br+/7RVc8YvvBleqxsmOF2yxGEH+65IDaK9NFK3UWC9gBwGH9WwzWpktk IMXXA1QSsy8ptx65Qyqicd3G5ndoaFx8vNDxuil9w5V5Vr2VXsBh3/xPwE+FjuZIfwi+ xC1i9cA+XzCpIDaI7v5G4EA8rRMzHePW/4Cry4uxNhutL/nmIosU9SWRHVXDE4QvnuTi cg5m7BxnHWNTtBClNZRcqj/99D4pR/sAcZt5+eoBupzOcnMv4pKq0cQSa5BDKM4z26ks V6pQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=NJnQ9oOI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n5-20020a05640206c500b0043a6defcbafsi7254203edy.219.2022.08.09.04.13.39; Tue, 09 Aug 2022 04:14:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=NJnQ9oOI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240297AbiHILFL (ORCPT + 99 others); Tue, 9 Aug 2022 07:05:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230178AbiHILFJ (ORCPT ); Tue, 9 Aug 2022 07:05:09 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A10C1FCCB; Tue, 9 Aug 2022 04:05:08 -0700 (PDT) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2799xcRU028593; Tue, 9 Aug 2022 11:04:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : from : to : references : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=oBwBvZSsMZBHlODzJPdCUM/1aMAkHwPlD1L/widFSYM=; b=NJnQ9oOIw76+f8+HDjnrPG/K99bdemZGeB96PP6JQ+zqgLru5UgQSXVveogcsPKNkBr9 hMZL/dxsY9z+PRGws0y0bUh1sXY8q7Y4k20RDcJZQs+Q4QbFi4qa2/jRXdUxBeNZGL/B Ti0gCKfP0Cr8s6/TtQzw49HbO4JuwYOXPLHLO2aOEn7NuL1veUDsdRpQgDN/HTucBo1g p5jns6MMb1/99zxKPjy73/E/HkHwfUhIcoUQ5OEmn5/qbNKQOsxY9Ck9H+YBH8f/pcCn R0Dn/wc1958W7xhJAm3tpzyI94lFRSkmgwIaH7BmWUX0CfRrCV0uBltpDbkA8tPvFaOF qA== Received: from nasanppmta02.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3hudw7gy21-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Aug 2022 11:04:30 +0000 Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.47.97.222]) by NASANPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 279B4TCn030507 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Aug 2022 11:04:29 GMT Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 9 Aug 2022 04:04:28 -0700 Received: from [10.216.39.97] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 9 Aug 2022 04:04:23 -0700 Message-ID: Date: Tue, 9 Aug 2022 16:34:19 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 7/8] remoteproc: qcom: Add support for memory sandbox Content-Language: en-US From: Srinivasa Rao Mandadapu To: Dmitry Baryshkov , , , , , , , , , , , , , , , , , References: <1659536480-5176-1-git-send-email-quic_srivasam@quicinc.com> <1659536480-5176-8-git-send-email-quic_srivasam@quicinc.com> <9d78a571-8d02-2967-1f29-21ca737a582f@linaro.org> <1f340f3d-83f3-6455-7671-34ef40abe6c4@quicinc.com> Organization: Qualcomm In-Reply-To: <1f340f3d-83f3-6455-7671-34ef40abe6c4@quicinc.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: E2pb8Cu3XOPQluXqIQK3YMZZ8yR8U_01 X-Proofpoint-ORIG-GUID: E2pb8Cu3XOPQluXqIQK3YMZZ8yR8U_01 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-09_03,2022-08-09_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=999 clxscore=1011 spamscore=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 adultscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208090048 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/9/2022 1:52 PM, Srinivasa Rao Mandadapu wrote: > > On 8/7/2022 2:04 AM, Dmitry Baryshkov wrote: > Thanks for your time and Valuable inputs Dmitry!!! >> On 03/08/2022 17:21, Srinivasa Rao Mandadapu wrote: >>> Add memory sandbox support for ADSP based platforms secure booting. >> >> This repeats commit subject. Please replace it with proper commit >> message text describing what is done and why. > Okay. Will update it. >> >>> >>> Signed-off-by: Srinivasa Rao Mandadapu >>> --- >>>   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 >>> @@ -9,6 +9,7 @@ >>>   #include >>>   #include >>>   #include >>> +#include >>>   #include >>>   #include >>>   #include >>> @@ -48,6 +49,8 @@ >>>   #define LPASS_PWR_ON_REG        0x10 >>>   #define LPASS_HALTREQ_REG        0x0 >>>   +#define SID_MASK_DEFAULT        0xF >>> + >>>   #define QDSP6SS_XO_CBCR        0x38 >>>   #define QDSP6SS_CORE_CBCR    0x20 >>>   #define QDSP6SS_SLEEP_CBCR    0x3c >>> @@ -77,7 +80,7 @@ struct adsp_pil_data { >>>   struct qcom_adsp { >>>       struct device *dev; >>>       struct rproc *rproc; >>> - >>> +    struct iommu_domain *iommu_dom; >>>       struct qcom_q6v5 q6v5; >>>         struct clk *xo; >>> @@ -332,6 +335,91 @@ static int adsp_load(struct rproc *rproc, const >>> struct firmware *fw) >>>       return 0; >>>   } >>>   +static int adsp_map_smmu(struct qcom_adsp *adsp, struct rproc >>> *rproc) >>> +{ >>> +    struct of_phandle_args args; >>> +    int ret, rc, i; >>> +    long long sid; >>> + >>> +    unsigned long mem_phys; >>> +    unsigned long iova; >>> +    const __be32 *prop; >>> +    int access_level; >>> +    uint32_t len, flag, mem_size; >>> +    int offset; >>> +    struct fw_rsc_hdr *hdr; >>> +    struct fw_rsc_devmem *rsc_fw; >>> + >>> +    rc = of_parse_phandle_with_fixed_args(adsp->dev->of_node, >>> "iommus", 1, 0, &args); >> >> Please do not add implicit dependency on #iommu-cells value. > Okay. Will change it to "of_parse_phandle_with_args()" >> >>> +    if (rc < 0) >>> +        sid = -1; >>> +    else >>> +        sid = args.args[0] & SID_MASK_DEFAULT; >>> + >>> +    adsp->iommu_dom = iommu_domain_alloc(&platform_bus_type); >> >> please use adsp->dev->bus instead of platform_bus_type here. > Okay. will update it. >> >>> +    if (!adsp->iommu_dom) { >>> +        dev_err(adsp->dev, "failed to allocate iommu domain\n"); >>> +        return -ENOMEM; >>> +    } >>> + >>> +    ret = iommu_attach_device(adsp->iommu_dom, adsp->dev); >>> +    if (ret) { >>> +        dev_err(adsp->dev, "could not attach device ret = %d\n", ret); >>> +        return -EBUSY; >>> +    } >>> + >>> +    /* Add SID configuration for ADSP Firmware to SMMU */ >>> +    adsp->mem_phys =  adsp->mem_phys | (sid << 32); >>> + >>> +    ret = iommu_map(adsp->iommu_dom, adsp->mem_phys, adsp->mem_phys, >>> +            adsp->mem_size,    IOMMU_READ | IOMMU_WRITE); >>> +    if (ret) { >>> +        dev_err(adsp->dev, "Unable to map ADSP Physical Memory\n"); >>> +        return ret; >>> +    } >>> + >>> +    prop = of_get_property(adsp->dev->of_node, "qcom,adsp-memory", >>> &len); >> >> Non-documented property. So, this chunk is not acceptable. > Okay. Will add it in dt-bindings too. >> >>> +    if (prop) { >>> +        len /= sizeof(__be32); >>> +        for (i = 0; i < len; i++) { >>> +            iova = be32_to_cpu(prop[i++]); >>> +            mem_phys = be32_to_cpu(prop[i++]); >>> +            mem_size = be32_to_cpu(prop[i++]); >>> +            access_level = be32_to_cpu(prop[i]); >>> + >>> +            if (access_level) >>> +                flag = IOMMU_READ | IOMMU_WRITE; >>> +            else >>> +                flag = IOMMU_READ; >>> + >>> +            ret = iommu_map(adsp->iommu_dom, iova, mem_phys, >>> mem_size, flag); >>> +            if (ret) { >>> +                dev_err(adsp->dev, "failed to map addr = %p >>> mem_size = %x\n", >>> +                        &(mem_phys), mem_size); >>> +                return ret; >>> +            } >>> +        } >>> +    } else { >>> +        if (!rproc->table_ptr) >>> +            return 0; >>> + >>> +        for (i = 0; i < rproc->table_ptr->num; i++) { >>> +            offset = rproc->table_ptr->offset[i]; >>> +            hdr = (void *)rproc->table_ptr + offset; >>> +            rsc_fw = (struct fw_rsc_devmem *)hdr + sizeof(*hdr); >>> + >>> +            ret = iommu_map(rproc->domain, rsc_fw->da, rsc_fw->pa, >>> +                        rsc_fw->len, rsc_fw->flags); >> >> What about filling an sgtable instead and using it? > > Here we are just doing IO mapping and allowing ADSP to access the > specified memory. > > I am not sure,  sg_table applicable here or not as it's not any DMA > activity. > > Please correct me if my understanding is not enough and It would help > me a lot, if any good example shared. > >> >>> +            if (ret) { >>> +                pr_err("%s; unable to map adsp memory address\n", >>> __func__); >>> +                return ret; >>> +            } >>> +        } >>> +    } >>> +    return 0; >>> +} >>> + >>> + >>>   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); >> >> Is this also applicable to cDSP? To sdm845 adsp? > > It's applicable to all ADSP SoC variants. I think it's better to add > adsp flag("is_adsp") for > > distinguishing adsp use cases. Please suggest here. Verified with sdm845 developer, and got to know that, even though it's applicable there too, Somehow for them it was working without memory sandboxing. Maybe, it was due to SMMU security levels were different. > >> >>> +        if (ret) { >>> +            dev_err(adsp->dev, "ADSP smmu mapping failed\n"); >>> +            goto adsp_smmu_unmap; >>> +        } >>> +    } >>>       ret = clk_prepare_enable(adsp->xo); >>>       if (ret) >>>           goto disable_irqs; >>> @@ -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); >>>         return ret; >>>   } >> >>