Message ID | 1669897248-23052-1-git-send-email-quic_srivasam@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp233042wrr; Thu, 1 Dec 2022 04:31:52 -0800 (PST) X-Google-Smtp-Source: AA0mqf4jGq3XSr2w3C2NlFaifSieNh3xtwsGv9O9NB0RTFGis66tyl0XG8ERWqrwgCGF8thw8DTP X-Received: by 2002:a17:90a:2b8c:b0:212:f4f1:96ee with SMTP id u12-20020a17090a2b8c00b00212f4f196eemr78149950pjd.72.1669897912486; Thu, 01 Dec 2022 04:31:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669897912; cv=none; d=google.com; s=arc-20160816; b=VaCbfBZ25pHZdK0OKjVRHomLDKrHFrm4YKGgyJv6G0LIyh/lKNJKFR2bmNRCI+RCx1 Slvtb9KCapushnLpUaoPA/ZOoI3atL8eSWgUqnzT6QsZs7+wN/EPJiOSax4kdLYmUSpC gg7qViYTSZ8tNfMB2mogNw3wXwAadosLX0R7BXdKgJ7kHVWU41YV8bRd1fyZxybXzoU0 lRUGOl7G/QuhJb+YKcUSzKVmu5z6R26D3EmIA+97gwec3LU10jkhDgRsSIU3Jcgfae8u YrcAecl1EB297PnqUB5FAA6wWtIIBfNC1sz6h8QsI4YzWuv8++zoZdrZqfgT9LDQSAGi lSjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=o35YdJaFszQepz90vSPHt6PmoQ0SOBopmc9imxmtMi4=; b=OrrmkPhTfUexVZ7SUmcVwmCK0yvoUrLDC3unD4Oi5jymTz1AkjLTI4940n6Gf1ZEwi BWWpc5/a75Aty3JwKaSaZtwE/XgB0o9jxZQRHC/UoeHocajwanVubcFw5CdiNhOYXu8A oVbA6IQJSogOXI7RpHO4RCqIxtUhfyDfZb/z/2USN1eilAAOouKsXrXH8pqBuAQsjuY2 dKn2dJSvFpFEtZcNZQUjqXFWfjVo/bkbMjZ8nQn48Hox5FKR0WS6HgK7A2j9wFsflvIY 7RK7TiLeyw/5XpU1UmFMXwOhsDi3OHsNQmpuMFtUjP8HoHJUs/AuQl9cYbsp520CYTtx 3nkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=QGD6d4tS; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t8-20020a056a00138800b005728c05ef9esi5123683pfg.14.2022.12.01.04.31.39; Thu, 01 Dec 2022 04:31:52 -0800 (PST) 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=QGD6d4tS; 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 S230258AbiLAMV3 (ORCPT <rfc822;heyuhang3455@gmail.com> + 99 others); Thu, 1 Dec 2022 07:21:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230525AbiLAMVZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 1 Dec 2022 07:21:25 -0500 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FACDAB029; Thu, 1 Dec 2022 04:21:23 -0800 (PST) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B1ANOfC006098; Thu, 1 Dec 2022 12:21:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=qcppdkim1; bh=o35YdJaFszQepz90vSPHt6PmoQ0SOBopmc9imxmtMi4=; b=QGD6d4tSFCEEPU7eOuvRDB85ZYZTtpthi1LrnlP9fhsaqDcMSgCarEGrs+FH1mUDP25c WKXWp6mnjfEgy0toM1SS2GON2lKQ+zFGLZHmf6cvG5Qec2fXKbvPhR1g8mEYP8BQHlSq 4CllCTsiQWrZeQ9chG8dB2LAO3ABX8NFhwGgr8b8FlauZsN25z4udiJJmKLqcECZfIA3 JMNsooZrpHcwyl6dkp2FZnNBSatq/e/7/UBoHc7NOOmWD3VMl0ODv3WGvGPiFeFJrWu+ lyT4ERMLamNLVgn5xjwltu4KJbW1eySagiukxL09I9IGOmEqvrD4LP/E+ia43adxNiES Qw== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3m6k3qs9nb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Dec 2022 12:21:09 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 2B1CL8rB021799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Dec 2022 12:21:08 GMT Received: from hu-srivasam-hyd.qualcomm.com (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.36; Thu, 1 Dec 2022 04:21:02 -0800 From: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> To: <linux-remoteproc@vger.kernel.org>, <agross@kernel.org>, <andersson@kernel.org>, <lgirdwood@gmail.com>, <broonie@kernel.org>, <robh+dt@kernel.org>, <quic_plai@quicinc.com>, <bgoswami@quicinc.com>, <perex@perex.cz>, <tiwai@suse.com>, <srinivas.kandagatla@linaro.org>, <quic_rohkumar@quicinc.com>, <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <swboyd@chromium.org>, <judyhsiao@chromium.org>, <devicetree@vger.kernel.org>, <krzysztof.kozlowski@linaro.org>, <mathieu.poirier@linaro.org> CC: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Subject: [PATCH] remoteproc: elf_loader: Update resource table name check Date: Thu, 1 Dec 2022 17:50:48 +0530 Message-ID: <1669897248-23052-1-git-send-email-quic_srivasam@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain 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: 92nkJW-q8lJX3ix6rnVlv9-0RirJcWu6 X-Proofpoint-ORIG-GUID: 92nkJW-q8lJX3ix6rnVlv9-0RirJcWu6 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-01_04,2022-12-01_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 adultscore=0 spamscore=0 priorityscore=1501 clxscore=1011 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212010088 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751014873490696334?= X-GMAIL-MSGID: =?utf-8?q?1751014873490696334?= |
Series |
remoteproc: elf_loader: Update resource table name check
|
|
Commit Message
Srinivasa Rao Mandadapu
Dec. 1, 2022, 12:20 p.m. UTC
Update resource table name check with sub string search instead of
complete string search.
In general Qualcomm binary contains, section header name
(e.g. .resource_table), amended with extra string to differentiate
with other sections.
So far Android adsp binaries are being authenticated using TZ,
hence this mismatch hasn't created any problem.
In recent developments, ADSP binary is being used in Chrome based
platforms, which doesn't have TZ path, hence resource table is
required for memory sandboxing.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
---
drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Quoting Srinivasa Rao Mandadapu (2022-12-01 04:20:48) > Update resource table name check with sub string search instead of > complete string search. > In general Qualcomm binary contains, section header name > (e.g. .resource_table), amended with extra string to differentiate > with other sections. > So far Android adsp binaries are being authenticated using TZ, > hence this mismatch hasn't created any problem. > In recent developments, ADSP binary is being used in Chrome based > platforms, which doesn't have TZ path, hence resource table is > required for memory sandboxing. > Does this need a Fixes tag? > Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> > --- > drivers/remoteproc/remoteproc_elf_loader.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > index 5a412d7..0feb120 100644 > --- a/drivers/remoteproc/remoteproc_elf_loader.c > +++ b/drivers/remoteproc/remoteproc_elf_loader.c > @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) > u64 offset = elf_shdr_get_sh_offset(class, shdr); > u32 name = elf_shdr_get_sh_name(class, shdr); > > - if (strcmp(name_table + name, ".resource_table")) > + if (!strstr(name_table + name, ".resource_table")) Was the strcmp not working before because the 'name_table' has something else in it? It really looks like your elf file is malformed.
On 12/7/2022 7:25 AM, Stephen Boyd wrote: Thanks for Your Time Stephen!!! > Quoting Srinivasa Rao Mandadapu (2022-12-01 04:20:48) >> Update resource table name check with sub string search instead of >> complete string search. >> In general Qualcomm binary contains, section header name >> (e.g. .resource_table), amended with extra string to differentiate >> with other sections. >> So far Android adsp binaries are being authenticated using TZ, >> hence this mismatch hasn't created any problem. >> In recent developments, ADSP binary is being used in Chrome based >> platforms, which doesn't have TZ path, hence resource table is >> required for memory sandboxing. >> > Does this need a Fixes tag? I don't think so. I feel It's kind of enhancement. > >> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> >> --- >> drivers/remoteproc/remoteproc_elf_loader.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c >> index 5a412d7..0feb120 100644 >> --- a/drivers/remoteproc/remoteproc_elf_loader.c >> +++ b/drivers/remoteproc/remoteproc_elf_loader.c >> @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) >> u64 offset = elf_shdr_get_sh_offset(class, shdr); >> u32 name = elf_shdr_get_sh_name(class, shdr); >> >> - if (strcmp(name_table + name, ".resource_table")) >> + if (!strstr(name_table + name, ".resource_table")) > Was the strcmp not working before because the 'name_table' has something > else in it? It really looks like your elf file is malformed. Actually, DSP binary is prepared by combining different elfs. So Section header names are appended with something else to distinguish same section name of different elfs, by using some Qualcomm specific QURT scripts. Hence final binary contains resource_table name appended with module specific name. So this patch is required to handle such modified name.
Quoting Srinivasa Rao Mandadapu (2022-12-08 05:40:54) > > On 12/7/2022 7:25 AM, Stephen Boyd wrote: > Thanks for Your Time Stephen!!! > > Quoting Srinivasa Rao Mandadapu (2022-12-01 04:20:48) > >> Update resource table name check with sub string search instead of > >> complete string search. > >> In general Qualcomm binary contains, section header name > >> (e.g. .resource_table), amended with extra string to differentiate > >> with other sections. > >> So far Android adsp binaries are being authenticated using TZ, > >> hence this mismatch hasn't created any problem. > >> In recent developments, ADSP binary is being used in Chrome based > >> platforms, which doesn't have TZ path, hence resource table is > >> required for memory sandboxing. > >> > > Does this need a Fixes tag? > I don't think so. I feel It's kind of enhancement. > > > >> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> > >> --- > >> drivers/remoteproc/remoteproc_elf_loader.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > >> index 5a412d7..0feb120 100644 > >> --- a/drivers/remoteproc/remoteproc_elf_loader.c > >> +++ b/drivers/remoteproc/remoteproc_elf_loader.c > >> @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) > >> u64 offset = elf_shdr_get_sh_offset(class, shdr); > >> u32 name = elf_shdr_get_sh_name(class, shdr); > >> > >> - if (strcmp(name_table + name, ".resource_table")) > >> + if (!strstr(name_table + name, ".resource_table")) > > Was the strcmp not working before because the 'name_table' has something > > else in it? It really looks like your elf file is malformed. > > Actually, DSP binary is prepared by combining different elfs. So Section > header names are appended with > > something else to distinguish same section name of different elfs, by > using some Qualcomm specific QURT scripts. > Hence final binary contains resource_table name appended with module > specific name. > > So this patch is required to handle such modified name. > Can you clarify how the section header name looks? Probably you can objdump the section here and provide that information to help us understand. I think remoteproc_elf_loader.c assumes the ELF file is properly formed. There should be a section named '.resource_table', so the strcmp will find it by looking at the section header names.
On 12/1/2022 8:20 PM, Srinivasa Rao Mandadapu wrote: > Update resource table name check with sub string search instead of > complete string search. > In general Qualcomm binary contains, section header name > (e.g. .resource_table), amended with extra string to differentiate > with other sections. > So far Android adsp binaries are being authenticated using TZ, > hence this mismatch hasn't created any problem. > In recent developments, ADSP binary is being used in Chrome based > platforms, which doesn't have TZ path, hence resource table is > required for memory sandboxing. > > Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> > --- > drivers/remoteproc/remoteproc_elf_loader.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > index 5a412d7..0feb120 100644 > --- a/drivers/remoteproc/remoteproc_elf_loader.c > +++ b/drivers/remoteproc/remoteproc_elf_loader.c > @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) > u64 offset = elf_shdr_get_sh_offset(class, shdr); > u32 name = elf_shdr_get_sh_name(class, shdr); > > - if (strcmp(name_table + name, ".resource_table")) > + if (!strstr(name_table + name, ".resource_table")) > continue; How about ? if (strcmp(name_table + name, ".resource_table")) { if (strstr(name_table + name, ".resource_table")) break; continue; } Regards, Peng. > > table = (struct resource_table *)(elf_data + offset);
On 12/10/2022 2:22 AM, Stephen Boyd wrote: Thanks for your time Stephen!!! > Quoting Srinivasa Rao Mandadapu (2022-12-08 05:40:54) >> On 12/7/2022 7:25 AM, Stephen Boyd wrote: >> Thanks for Your Time Stephen!!! >>> Quoting Srinivasa Rao Mandadapu (2022-12-01 04:20:48) >>>> Update resource table name check with sub string search instead of >>>> complete string search. >>>> In general Qualcomm binary contains, section header name >>>> (e.g. .resource_table), amended with extra string to differentiate >>>> with other sections. >>>> So far Android adsp binaries are being authenticated using TZ, >>>> hence this mismatch hasn't created any problem. >>>> In recent developments, ADSP binary is being used in Chrome based >>>> platforms, which doesn't have TZ path, hence resource table is >>>> required for memory sandboxing. >>>> >>> Does this need a Fixes tag? >> I don't think so. I feel It's kind of enhancement. >>>> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> >>>> --- >>>> drivers/remoteproc/remoteproc_elf_loader.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c >>>> index 5a412d7..0feb120 100644 >>>> --- a/drivers/remoteproc/remoteproc_elf_loader.c >>>> +++ b/drivers/remoteproc/remoteproc_elf_loader.c >>>> @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) >>>> u64 offset = elf_shdr_get_sh_offset(class, shdr); >>>> u32 name = elf_shdr_get_sh_name(class, shdr); >>>> >>>> - if (strcmp(name_table + name, ".resource_table")) >>>> + if (!strstr(name_table + name, ".resource_table")) >>> Was the strcmp not working before because the 'name_table' has something >>> else in it? It really looks like your elf file is malformed. >> Actually, DSP binary is prepared by combining different elfs. So Section >> header names are appended with >> >> something else to distinguish same section name of different elfs, by >> using some Qualcomm specific QURT scripts. >> Hence final binary contains resource_table name appended with module >> specific name. >> >> So this patch is required to handle such modified name. >> > Can you clarify how the section header name looks? Probably you can > objdump the section here and provide that information to help us > understand. Here is the Section header info. $ readelf -SW bootimage_relocflag_kodiak.adsp.prodQ.pbn There are 65 section headers, starting at offset 0x434: readelf: Error: File contains multiple dynamic symbol tables Section Headers: [Nr] Name Type [ 0] NULL [ 1] .shstrtab STRTAB [ 2] .text.ukernel.island PROGBITS [ 3] .data.ukernel.island PROGBITS [ 4] .qskernel_exports.island PROGBITS [ 5] .start PROGBITS [ 6] .qskernel_main PROGBITS [ 7] .qskernel_rest PROGBITS [ 8] .comment PROGBITS [ 9] .data.common.island PROGBITS [10] .rodata.common.island PROGBITS [11] .data.va.island NOBITS [12] .rodata.va.island PROGBITS [13] .text.common.island PROGBITS [14] .text.va.island PROGBITS [15] .start PROGBITS [16] .ukernel.main PROGBITS [17] .init PROGBITS [18] .text PROGBITS [19] .fini PROGBITS [20] .interp PROGBITS [21] .hash HASH [22] .dynsym DYNSYM [23] .dynstr STRTAB [24] .rodata PROGBITS [25] .eh_frame PROGBITS [26] .ctors PROGBITS [27] .dtors PROGBITS [28] .dynamic DYNAMIC [29] .data PROGBITS [30] .bss NOBITS [31] .sdata PROGBITS [32] QSR_STRING PROGBITS [33] .comment PROGBITS [34] .tcm_island.audio_process PROGBITS [35] .data.common.island.audio_process PROGBITS [36] .rodata.common.island.audio_process PROGBITS [37] .data.va.island.audio_process PROGBITS [38] .rodata.va.island.audio_process PROGBITS [39] .text.common.island.audio_process PROGBITS [40] .text.va.island.audio_process PROGBITS [41] .start.audio_process PROGBITS [42] .init.audio_process PROGBITS [43] .text.audio_process PROGBITS [44] .fini.audio_process PROGBITS [45] .interp.audio_process PROGBITS [46] .hash.audio_process HASH [47] .dynsym.audio_process DYNSYM [48] .dynstr.audio_process STRTAB [49] .rodata.audio_process PROGBITS [50] .eh_frame.audio_process PROGBITS [51] .ctors.audio_process PROGBITS [52] .dtors.audio_process PROGBITS [53] .data.rel.ro.audio_process PROGBITS [54] .dynamic.audio_process DYNAMIC [55] .data.audio_process PROGBITS [56] .bss.audio_process NOBITS [57] .sdata.audio_process PROGBITS [58] QSR_STRING.audio_process PROGBITS [59] .comment.audio_process PROGBITS [60] .start.ac_bin_process PROGBITS [61] .resource_table.ac_bin_process PROGBITS [62] .comment.ac_bin_process PROGBITS > > I think remoteproc_elf_loader.c assumes the ELF file is properly formed. > There should be a section named '.resource_table', so the strcmp will > find it by looking at the section header names.
On 12/10/2022 8:36 AM, Peng Fan wrote: Thanks for your time and valuable suggestion Pang!!! > > On 12/1/2022 8:20 PM, Srinivasa Rao Mandadapu wrote: >> Update resource table name check with sub string search instead of >> complete string search. >> In general Qualcomm binary contains, section header name >> (e.g. .resource_table), amended with extra string to differentiate >> with other sections. >> So far Android adsp binaries are being authenticated using TZ, >> hence this mismatch hasn't created any problem. >> In recent developments, ADSP binary is being used in Chrome based >> platforms, which doesn't have TZ path, hence resource table is >> required for memory sandboxing. >> >> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> >> --- >> drivers/remoteproc/remoteproc_elf_loader.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c >> b/drivers/remoteproc/remoteproc_elf_loader.c >> index 5a412d7..0feb120 100644 >> --- a/drivers/remoteproc/remoteproc_elf_loader.c >> +++ b/drivers/remoteproc/remoteproc_elf_loader.c >> @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct >> firmware *fw) >> u64 offset = elf_shdr_get_sh_offset(class, shdr); >> u32 name = elf_shdr_get_sh_name(class, shdr); >> - if (strcmp(name_table + name, ".resource_table")) >> + if (!strstr(name_table + name, ".resource_table")) >> continue; > > How about ? > if (strcmp(name_table + name, ".resource_table")) { > if (strstr(name_table + name, ".resource_table")) > break; > continue; > } It looks valid approach to me. But other reviewers may object on double check. Let's see Stephen Boyd comments also, and handle it accordingly. > > Regards, > Peng. >> table = (struct resource_table *)(elf_data + offset);
Quoting Srinivasa Rao Mandadapu (2022-12-12 05:49:29) > > On 12/10/2022 2:22 AM, Stephen Boyd wrote: > Thanks for your time Stephen!!! > > Quoting Srinivasa Rao Mandadapu (2022-12-08 05:40:54) > >> On 12/7/2022 7:25 AM, Stephen Boyd wrote: > >> Thanks for Your Time Stephen!!! > >>> Quoting Srinivasa Rao Mandadapu (2022-12-01 04:20:48) > >>>> Update resource table name check with sub string search instead of > >>>> complete string search. > >>>> In general Qualcomm binary contains, section header name > >>>> (e.g. .resource_table), amended with extra string to differentiate > >>>> with other sections. > >>>> So far Android adsp binaries are being authenticated using TZ, > >>>> hence this mismatch hasn't created any problem. > >>>> In recent developments, ADSP binary is being used in Chrome based > >>>> platforms, which doesn't have TZ path, hence resource table is > >>>> required for memory sandboxing. > >>>> > >>> Does this need a Fixes tag? > >> I don't think so. I feel It's kind of enhancement. > >>>> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> > >>>> --- > >>>> drivers/remoteproc/remoteproc_elf_loader.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > >>>> index 5a412d7..0feb120 100644 > >>>> --- a/drivers/remoteproc/remoteproc_elf_loader.c > >>>> +++ b/drivers/remoteproc/remoteproc_elf_loader.c > >>>> @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) > >>>> u64 offset = elf_shdr_get_sh_offset(class, shdr); > >>>> u32 name = elf_shdr_get_sh_name(class, shdr); > >>>> > >>>> - if (strcmp(name_table + name, ".resource_table")) > >>>> + if (!strstr(name_table + name, ".resource_table")) > >>> Was the strcmp not working before because the 'name_table' has something > >>> else in it? It really looks like your elf file is malformed. > >> Actually, DSP binary is prepared by combining different elfs. So Section > >> header names are appended with > >> > >> something else to distinguish same section name of different elfs, by > >> using some Qualcomm specific QURT scripts. > >> Hence final binary contains resource_table name appended with module > >> specific name. > >> > >> So this patch is required to handle such modified name. > >> > > Can you clarify how the section header name looks? Probably you can > > objdump the section here and provide that information to help us > > understand. > > Here is the Section header info. > > $ readelf -SW bootimage_relocflag_kodiak.adsp.prodQ.pbn > There are 65 section headers, starting at offset 0x434: > readelf: Error: File contains multiple dynamic symbol tables > [...] > [60] .start.ac_bin_process PROGBITS > [61] .resource_table.ac_bin_process PROGBITS Cool, the readelf output is helpful. Please rewrite the commit text to include this detail. It wasn't obvious to me what 'amended' meant. You probably mean "appended", which clarifies that it has a string added to the end. I'm also not sure why TZ or not TZ matters for the resource table section. It may be meaningful to you, but to others it doesn't have any relation to this resource table appending scheme so it is not helpful by itself. Either way, this is not up to me as I'm not the maintainer of remoteproc. I peeked at the documentation, but this section name isn't clearly defined. It seems to just be how it has been for a long time. Maybe you can also update the documentation (Documentation/staging/remoteproc.rst) to indicate that this elf section can have anything appended after it, but it must start with ".resource_table"? That would help everyone. And I don't know why that's in the staging directory. Bjorn? Finally, I'd prefer the use of strstarts() instead so it is clear what you're trying to implement.
diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c index 5a412d7..0feb120 100644 --- a/drivers/remoteproc/remoteproc_elf_loader.c +++ b/drivers/remoteproc/remoteproc_elf_loader.c @@ -272,7 +272,7 @@ find_table(struct device *dev, const struct firmware *fw) u64 offset = elf_shdr_get_sh_offset(class, shdr); u32 name = elf_shdr_get_sh_name(class, shdr); - if (strcmp(name_table + name, ".resource_table")) + if (!strstr(name_table + name, ".resource_table")) continue; table = (struct resource_table *)(elf_data + offset);