From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B987EC433F5 for ; Wed, 5 Oct 2022 16:49:16 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 60E4184D7B; Wed, 5 Oct 2022 18:49:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=hypervisor.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=hypervisor.org header.i=@hypervisor.org header.b="KjGyDgQh"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7227584C7D; Tue, 4 Oct 2022 21:36:15 +0200 (CEST) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4B20084D5E for ; Tue, 4 Oct 2022 21:36:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=hypervisor.org Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=udo@hypervisor.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1664912165; s=strato-dkim-0002; d=hypervisor.org; h=Message-ID:Subject:To:From:Date:Cc:Date:From:Subject:Sender; bh=qdRfIhx/uqjaA9PQ3DMqlgeBid2vQc1qWlR5SorhuNo=; b=KjGyDgQhqAvqrdcO2MtHwOlXaR//LbvwCta28oA0/nW9qBEzAtqRQkOVnfG6ZnI6eB vdV1j24D77Q8QwYjtckEH/TkkneElua7Jj5MP04jWI9EYYY+QLzswtwJZV2wy6RNfckO jVeLcKIpHsUgHsB5Dkg+DsGHwPcsGtmV+ZXEGMerliYBULwGaobwTEbxnMTJyftOPK3u Ha6b+FCt29iBqD0NIQ0ejPlfRuP1n8Cz8RjrHUOiU0AcEON2QA5BOBuVAjkjbFA2wFlP WbyL+bFScCvj4ht+tab4NoWaoOoC8w0OsQnSjSrOinNMaL8TwkFKhyCuoc42F9FgqEmk +tnw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":OWgLVUixa/orYEjgByCmMbha6U0z53RZBchi0p8VsT1fAA5ylDfCvZjekVSzOVIZb08=" X-RZG-CLASS-ID: mo00 Received: from X220.hypervisor.org by smtp.strato.de (RZmta 48.1.3 DYNA|AUTH) with ESMTPSA id R90024y94Ja4Mc9 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Tue, 4 Oct 2022 21:36:04 +0200 (CEST) Date: Tue, 4 Oct 2022 21:36:04 +0200 From: Udo Steinberg To: u-boot@lists.denx.de Subject: [BUG] U-Boot can overwrite itself with "bootelf" command Message-ID: <20221004213604.64430b6e@X220.hypervisor.org> X-Mailer: X-Mailer 5.0 Gold MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 05 Oct 2022 18:48:53 +0200 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi, (please CC: me for replies, because I'm not subscribed to the list) While debugging a U-Boot 2022.10 hang on an NXP i.MX8 board during execution of the the "bootelf" command, I discovered the following general problem: 1) I have an aarch64 ELF binary that looks as follows: Program Header: LOAD off 0x00000000000000b0 vaddr 0x00000000ff000000 paddr 0x00000000ff000000 align 2**3 filesz 0x000000000000086c memsz 0x0000000000001000 flags rw- LOAD off 0x0000000000001000 vaddr 0x0000ff8000001000 paddr 0x00000000ff001000 align 2**11 filesz 0x000000000000f4dc memsz 0x0000000000fff000 flags rw- The second PHDR includes a rather large (~16MB) BSS that extends all the way up to the very end of DRAM. 2) U-Boot relocates itself to the end of DRAM (as per bdinfo): relocaddr = 0x00000000fff2c000 reloc off = 0x00000000bfd2c000 Build = 64-bit 3) When the ELF image from (1) is TFTP'd into memory (at some address ) and then launched via "bootelf -p ", U-Boot does not detect the conflict with its own image (2) and happily overwrites itself (causing the board to hang). The code in question that does the overwriting is in lib/elf.c in unsigned long load_elf64_image_phdr(unsigned long addr) here: /* Load each program header */ for (i = 0; i < ehdr->e_phnum; ++i) { void *dst = (void *)(ulong)phdr->p_paddr; void *src = (void *)addr + phdr->p_offset; debug("Loading phdr %i to 0x%p (%lu bytes)\n", i, dst, (ulong)phdr->p_filesz); if (phdr->p_filesz) memcpy(dst, src, phdr->p_filesz); if (phdr->p_filesz != phdr->p_memsz) ==> memset(dst + phdr->p_filesz, 0x00, phdr->p_memsz - phdr->p_filesz); flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN), roundup(phdr->p_memsz, ARCH_DMA_MINALIGN)); ++phdr; } IMHO U-Boot should refuse to load anything into the address range where U-Boot itself lives. Cheers, Udo