From patchwork Wed May 3 12:12:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Henri Roosen X-Patchwork-Id: 9709693 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 566B760387 for ; Wed, 3 May 2017 12:13:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 43DA420242 for ; Wed, 3 May 2017 12:13:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3866A2846C; Wed, 3 May 2017 12:13:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E19D420242 for ; Wed, 3 May 2017 12:13:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752176AbdECMNO (ORCPT ); Wed, 3 May 2017 08:13:14 -0400 Received: from mail.ginzinger.com ([31.193.165.229]:29344 "EHLO mail.ginzinger.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752090AbdECMNG (ORCPT ); Wed, 3 May 2017 08:13:06 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.ginzinger.com (Postfix) with ESMTP id 882593E87; Wed, 3 May 2017 14:13:06 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.10.1 (20141025) (Debian) at ginzinger.com Received: from mail.ginzinger.com ([127.0.0.1]) by localhost (mail.ginzinger.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpOzAfRmyDKY; Wed, 3 May 2017 14:13:05 +0200 (CEST) Received: from mail.ginzinger.com (unknown [10.1.1.201]) by mail.ginzinger.com (Postfix) with ESMTPS id 2FC653E5D; Wed, 3 May 2017 14:13:05 +0200 (CEST) Received: from EN-PC16.buero.ginzinger.com (10.2.1.65) by exc2.buero.ginzinger.com (10.1.1.201) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 3 May 2017 14:13:02 +0200 From: Henri Roosen To: CC: Henri Roosen , Ohad Ben-Cohen , Bjorn Andersson , open list Subject: [PATCH 1/1] remoteproc: fix elf_loader da_to_va translation and writing beyond segment Date: Wed, 3 May 2017 14:12:09 +0200 Message-ID: <1493813529-19184-1-git-send-email-henri.roosen@ginzinger.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 X-Originating-IP: [10.2.1.65] Sender: linux-remoteproc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Consider a system with 2 memory regions: 0x1fff8000 - 0x1fffffff: iram 0x21000000 - 0x21007fff: dram The .elf file for this system contains the following Program Headers: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000094 0x1fff8000 0x1fff8000 0x00240 0x00240 R 0x4 LOAD 0x0002e0 0x1fff8240 0x1fff8240 0x03d1c 0x03d1c RWE 0x10 LOAD 0x003ffc 0x21000000 0x1fffbf5c 0x001cc 0x048a0 RW 0x4 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .text .ARM .init_array .fini_array 02 .data .bss .heap .stack The problem is with the 3rd segment: it has 0x1cc bytes of ROM .data which need to be placed at PhysAddr 0x1fffbf5c. Using MemSiz as len parameter for rproc_da_to_va is incorrect (goes beyond 0x1fffffff). The correct len parameter to be used here is FileSiz. The actual memcpy of the segment was already correctly using the FileSiz for length, however the unnecessary "Zero out remaining memory" would write beyond the 0x1fffffff end of the memory region! This patch removes the harmful code. Signed-off-by: Henri Roosen --- drivers/remoteproc/remoteproc_elf_loader.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c index c523983..3fa159a 100644 --- a/drivers/remoteproc/remoteproc_elf_loader.c +++ b/drivers/remoteproc/remoteproc_elf_loader.c @@ -183,9 +183,10 @@ rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) } /* grab the kernel address for this device address */ - ptr = rproc_da_to_va(rproc, da, memsz); + ptr = rproc_da_to_va(rproc, da, filesz); if (!ptr) { - dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz); + dev_err(dev, "bad phdr da 0x%x filesz 0x%x\n", + da, filesz); ret = -EINVAL; break; } @@ -193,16 +194,6 @@ rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) /* put the segment where the remote processor expects it */ if (phdr->p_filesz) memcpy(ptr, elf_data + phdr->p_offset, filesz); - - /* - * Zero out remaining memory for this segment. - * - * This isn't strictly required since dma_alloc_coherent already - * did this for us. albeit harmless, we may consider removing - * this. - */ - if (memsz > filesz) - memset(ptr + filesz, 0, memsz - filesz); } return ret;