Message ID | 20221111061315.gonna.703-kees@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp571283wru; Thu, 10 Nov 2022 22:19:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf6COr7ld89QWhaQ622oe9r/Fxc6nQwUJkdgcKV6sJhjfo0lCD4myN3wsrcgXdYKvP+QGGqf X-Received: by 2002:a17:906:7d4d:b0:7a2:36c7:31ea with SMTP id l13-20020a1709067d4d00b007a236c731eamr729715ejp.210.1668147570632; Thu, 10 Nov 2022 22:19:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668147570; cv=none; d=google.com; s=arc-20160816; b=AqWRIPsvXbRl6guNViaUi6+iqhoDslOdA0yWyMgr+Wn5TEzg5ZhEVg1wauF8SX+4zN 3KRnbwkSIsHJg/jUDsXcsoaIwMMIufp/ugGKvnE8993NLI/KlIBerzygaAZRUXFk7yfI 3USesbMUlY5CPCeV/U00uN8y27qxq+24BB/IKF8e7KJ961pNcXrhWI/d/F3fMKg+cpeZ 9TCsKbUGDCIGkzpe5XbGikA4vm2kD0i1PjmVpag3koacdCc5KEKp1Q1lHurqOMXcL/T4 5HViZSGy3NnrSbNcU3senRnb6I1w+cQk735BvXkDysGEmNxv9gGiqwgO4S5CO7v1gR6p gweA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=LJbZhJS9Ev1XMOM4wW/EgY/OFSEa8D+Vt9N5SxaJSHs=; b=t1uCjJ57TipEJRbQGiCu7nmV1cl/fUS2B27wCqRl3NafBA+qto1R6D8bB/23seDXJp IEJO9aicBPNI3aos4YpUqhS1AE3vfn0Ovih4qXtBrvslPmnDw5DmmzmivINsTN4YW/OT eWFy0dqGdWMUUGq8CzMGxRGbkOhccVOonP/d4j0gU12hAXwtNi4ozTT49CkKnGmSEzhr pIWd9syDsPq/q8+NqrUXwXyp7b8A+6pTohGFaJ4wPwauZQ/3bL1lIZcYNtRWCLYcgRBW rpoELVG6SMAekN70ORQ+GoHGiKuHTV68CkV+FSzIxIY6L0lvefShrWTLOF2jmzdumAAx ah/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=a2uE97e3; 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=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w4-20020a056402268400b0045d3e06e4d5si1834076edd.389.2022.11.10.22.19.06; Thu, 10 Nov 2022 22:19:30 -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=@chromium.org header.s=google header.b=a2uE97e3; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232740AbiKKGN3 (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Fri, 11 Nov 2022 01:13:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232749AbiKKGNZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Nov 2022 01:13:25 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FC3BBB5 for <linux-kernel@vger.kernel.org>; Thu, 10 Nov 2022 22:13:23 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id k5so3616367pjo.5 for <linux-kernel@vger.kernel.org>; Thu, 10 Nov 2022 22:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=LJbZhJS9Ev1XMOM4wW/EgY/OFSEa8D+Vt9N5SxaJSHs=; b=a2uE97e3Dcchu89fkZ3gY9WePVwKJGjK7Up57d0kS7VljHzA93kFQnDEGoaNzk7akx FbE5jDsPkJoQOdhi2fpzKV0AMFBEuO7sqUB6aKbW50VryFTbonmAC0ItGTxOz55L/XJW 82c/fFG9f1otpcAjcMtZBQMf8sGiejXUweLag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LJbZhJS9Ev1XMOM4wW/EgY/OFSEa8D+Vt9N5SxaJSHs=; b=lmSsWYhExhLBs/XQbP7SazxLJXFMGW1I89sBcTHEuNXxYvQkiVSAu2Khw4xTyHFRDn zgTyV4ovJDPetHkZL7zeNOzBu7tM1x4y1LFXMF7GrJ6R71CrJQgCVcQg2fMcI7ZWd2AF usgkW0HJQwticR6V7GB2L3LgkFygIifpNVd19roqqhQDb9CSA6UYncuX6A3w0xz9zlX7 5ApI7/2QdGk7fyGSuD//Z5vtZYz/AuCaWnxiZYP/4ZPgQA/2cnH2DO2zCJ6Hbm1ZeZyd nrg4iAPzqUll0SGXwaTjek1IwjK1ieXqwypxL8uC+561zeZCO7eyN5Ry2ZWm/Ybvrwoi SAQw== X-Gm-Message-State: ANoB5pkAD8aVgGzjFly1NJB+L64moU2pymdl53dBGMmMqdQ/LtyUF3Mg LED03/eMDUB+PHZnD92lLaaeHA== X-Received: by 2002:a17:902:82c5:b0:188:547d:b142 with SMTP id u5-20020a17090282c500b00188547db142mr1151214plz.103.1668147202950; Thu, 10 Nov 2022 22:13:22 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id u6-20020a17090341c600b0017f9021ddc6sm738931ple.289.2022.11.10.22.13.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 22:13:22 -0800 (PST) From: Kees Cook <keescook@chromium.org> To: Pedro Falcato <pedro.falcato@gmail.com> Cc: Kees Cook <keescook@chromium.org>, Rich Felker <dalias@libc.org>, Fangrui Song <maskray@google.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Eric Biederman <ebiederm@xmission.com>, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH v2] binfmt_elf: Allow .bss in any interp PT_LOAD Date: Thu, 10 Nov 2022 22:13:20 -0800 Message-Id: <20221111061315.gonna.703-kees@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2024; h=from:subject:message-id; bh=Y24MMuXgCRmwN8M9lMQ21fXH3PL7d1cIRSZ/p8LhrwM=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBjbef/6hzUuUZGLGrWJBWxgKZYE29qBjmhTy3LRXQp irXkyeaJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCY23n/wAKCRCJcvTf3G3AJk3dEA CIXfVDmGV7/YBxAB4wFGgxUpRivIRXez/dovh1l8xssD3q3bjdUJrxkzCsPrcEE/xNrOZiIHiXYFJV fCcQfwtmeVU1WrRUCGhwPxnfuMweCUte6qAuXQNNrf0swBefm8UYxQ3J3PfLPSWas6F32v+4mGkMMH UW69zCp+/TB87IXYknrKqw8PiE3SdOeNnZhnwfuQH9VWlNvy4Z0r1A9WCduyTXODw6CNC6MzTZDBoX 6pUzR+XyqvJARUHcg5mjPXrTUX4Odh9VmKMRT/vL6H4jQxKg2gSj/fMmY6jTnRlgEY93I+82L0Jlag jZfXxNKbSiCD84qLRUJwhHtFfypBrQtDiQzyN3piesT0vUmPHxwAVez+lf6sPmJDxm+ZsvtpePbCgP 3Gw0WHeuR5naODEOwvE+mBJWMIKzDjSlrzsdQ74Wot+ZzvE5keQN08R4UWVeCcu0y5pMPsTORxZE7K rJSOOaKvAlEEqJ+mPrszpXCudNN1d655Jt2fUIJj5gM4MtzNnC5trkijk6OzYwcUUlCQd5ScyFKvlV jezeFCHDx1aimUkMkSLCBnkXbVSd2wklLcscSFVqZiHxEWygZzNFbs6NRSyFTemptbIKZTvpeR50lW nJ+zAROtHOVfVb4upzYWUVOn8+t8vEaSzruQdPPvEQrV4Xm9O0BbQOJytazA== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,URIBL_BLACK autolearn=no 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?1749178269808236412?= X-GMAIL-MSGID: =?utf-8?q?1749179506739862669?= |
Series |
[v2] binfmt_elf: Allow .bss in any interp PT_LOAD
|
|
Commit Message
Kees Cook
Nov. 11, 2022, 6:13 a.m. UTC
Traditionally, only the final PT_LOAD for load_elf_interp() supported
having p_memsz > p_filesz. Recently, lld's construction of musl's
libc.so on PowerPC64 started having two PT_LOAD program headers with
p_memsz > p_filesz.
As the least invasive change possible, check for p_memsz > p_filesz for
each PT_LOAD in load_elf_interp.
Reported-by: Rich Felker <dalias@libc.org>
Link: https://maskray.me/blog/2022-11-05-lld-musl-powerpc64
Cc: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
v2: I realized we need to retain the final padding call.
v1: https://lore.kernel.org/linux-hardening/20221111055747.never.202-kees@kernel.org/
---
fs/binfmt_elf.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
Comments
(+ sam@gentoo.org from Pedro Falcato's patch) On 2022-11-10, Kees Cook wrote: >Traditionally, only the final PT_LOAD for load_elf_interp() supported >having p_memsz > p_filesz. Recently, lld's construction of musl's >libc.so on PowerPC64 started having two PT_LOAD program headers with >p_memsz > p_filesz. > >As the least invasive change possible, check for p_memsz > p_filesz for >each PT_LOAD in load_elf_interp. > >Reported-by: Rich Felker <dalias@libc.org> >Link: https://maskray.me/blog/2022-11-05-lld-musl-powerpc64 >Cc: Pedro Falcato <pedro.falcato@gmail.com> >Cc: Fangrui Song <maskray@google.com> >Cc: Alexander Viro <viro@zeniv.linux.org.uk> >Cc: Eric Biederman <ebiederm@xmission.com> >Cc: linux-fsdevel@vger.kernel.org >Cc: linux-mm@kvack.org >Signed-off-by: Kees Cook <keescook@chromium.org> >--- >v2: I realized we need to retain the final padding call. >v1: https://lore.kernel.org/linux-hardening/20221111055747.never.202-kees@kernel.org/ >--- > fs/binfmt_elf.c | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > >diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c >index 528e2ac8931f..0a24bbbef1d6 100644 >--- a/fs/binfmt_elf.c >+++ b/fs/binfmt_elf.c >@@ -673,15 +673,25 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex, > last_bss = k; > bss_prot = elf_prot; > } >+ >+ /* >+ * Clear any p_memsz > p_filesz area up to the end >+ * of the page to wipe anything left over from the >+ * loaded file contents. >+ */ >+ if (last_bss > elf_bss && padzero(elf_bss)) Missing { But after fixing this, I get a musl ld.so error. >+ error = -EFAULT; >+ goto out; >+ } > } > } > > /* >- * Now fill out the bss section: first pad the last page from >- * the file up to the page boundary, and zero it from elf_bss >- * up to the end of the page. >+ * Finally, pad the last page from the file up to the page boundary, >+ * and zero it from elf_bss up to the end of the page, if this did >+ * not already happen with the last PT_LOAD. > */ >- if (padzero(elf_bss)) { >+ if (last_bss == elf_bss && padzero(elf_bss)) { > error = -EFAULT; > goto out; > } >-- >2.34.1 > I added a new section to https://maskray.me/blog/2022-11-05-lld-musl-powerpc64 Copying here: To test that the kernel ELF loader can handle more RW `PT_LOAD` program headers, we can create an executable with more RW `PT_LOAD` program headers with `p_filesz < p_memsz`. We can place a read-only section after `.bss` followed by a `SHT_NOBITS` `SHF_ALLOC|SHF_WRITE` section. The read-only section will form a read-only `PT_LOAD` while the RW section will form a RW `PT_LOAD`. ```text #--- a.c #include <assert.h> #include <stdio.h> extern const char toc[]; char nobits0[0] __attribute__((section(".nobits0"))); char nobits1[0] __attribute__((section(".nobits1"))); int main(void) { assert(toc[4096-1] == 0); for (int i = 0; i < 1024; i++) assert(nobits0[i] == 0); nobits0[0] = nobits0[1024-1] = 1; for (int i = 0; i < 4096; i++) assert(nobits1[i] == 0); nobits1[0] = nobits1[4096-1] = 1; puts("hello"); } #--- toc.s .section .toc,"aw",@nobits .globl toc toc: .space 4096 .section .ro0,"a"; .byte 255 .section .nobits0,"aw",@nobits; .space 1024 .section .ro1,"a"; .byte 255 .section .nobits1,"aw",@nobits; .space 4096 #--- a.lds SECTIONS { .ro0 : {} .nobits0 : {} .ro1 : {} .nobits1 : {} } INSERT AFTER .bss; ``` ```sh split-file a.txt a path/to/musl-gcc -Wl,--dynamic-linker=/lib/libc.so a/a.c a/a.lds -o toy ``` split-file is a utility in llvm-project.
On Thu, Nov 10, 2022 at 11:42:34PM -0800, Fangrui Song wrote: > (+ sam@gentoo.org from Pedro Falcato's patch) > > On 2022-11-10, Kees Cook wrote: > > Traditionally, only the final PT_LOAD for load_elf_interp() supported > > having p_memsz > p_filesz. Recently, lld's construction of musl's > > libc.so on PowerPC64 started having two PT_LOAD program headers with > > p_memsz > p_filesz. > > > > As the least invasive change possible, check for p_memsz > p_filesz for > > each PT_LOAD in load_elf_interp. > > > > Reported-by: Rich Felker <dalias@libc.org> > > Link: https://maskray.me/blog/2022-11-05-lld-musl-powerpc64 > > Cc: Pedro Falcato <pedro.falcato@gmail.com> > > Cc: Fangrui Song <maskray@google.com> > > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > > Cc: Eric Biederman <ebiederm@xmission.com> > > Cc: linux-fsdevel@vger.kernel.org > > Cc: linux-mm@kvack.org > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > v2: I realized we need to retain the final padding call. > > v1: https://lore.kernel.org/linux-hardening/20221111055747.never.202-kees@kernel.org/ > > --- > > fs/binfmt_elf.c | 18 ++++++++++++++---- > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > > index 528e2ac8931f..0a24bbbef1d6 100644 > > --- a/fs/binfmt_elf.c > > +++ b/fs/binfmt_elf.c > > @@ -673,15 +673,25 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex, > > last_bss = k; > > bss_prot = elf_prot; > > } > > + > > + /* > > + * Clear any p_memsz > p_filesz area up to the end > > + * of the page to wipe anything left over from the > > + * loaded file contents. > > + */ > > + if (last_bss > elf_bss && padzero(elf_bss)) > > Missing { > > But after fixing this, I get a musl ld.so error. > > > + error = -EFAULT; > > + goto out; > > + } > > } > > } > > > > /* > > - * Now fill out the bss section: first pad the last page from > > - * the file up to the page boundary, and zero it from elf_bss > > - * up to the end of the page. > > + * Finally, pad the last page from the file up to the page boundary, > > + * and zero it from elf_bss up to the end of the page, if this did > > + * not already happen with the last PT_LOAD. > > */ > > - if (padzero(elf_bss)) { > > + if (last_bss == elf_bss && padzero(elf_bss)) { > > error = -EFAULT; > > goto out; > > } > > -- > > 2.34.1 > > > > I added a new section to https://maskray.me/blog/2022-11-05-lld-musl-powerpc64 > Copying here: > > To test that the kernel ELF loader can handle more RW `PT_LOAD` program headers, we can create an executable with more RW `PT_LOAD` program headers with `p_filesz < p_memsz`. > We can place a read-only section after `.bss` followed by a `SHT_NOBITS` `SHF_ALLOC|SHF_WRITE` section. The read-only section will form a read-only `PT_LOAD` while the RW section will form a RW `PT_LOAD`. > > ```text > #--- a.c > #include <assert.h> > #include <stdio.h> > > extern const char toc[]; > char nobits0[0] __attribute__((section(".nobits0"))); > char nobits1[0] __attribute__((section(".nobits1"))); > > int main(void) { > assert(toc[4096-1] == 0); > for (int i = 0; i < 1024; i++) > assert(nobits0[i] == 0); > nobits0[0] = nobits0[1024-1] = 1; > for (int i = 0; i < 4096; i++) > assert(nobits1[i] == 0); > nobits1[0] = nobits1[4096-1] = 1; > > puts("hello"); > } > > #--- toc.s > .section .toc,"aw",@nobits > .globl toc > toc: > .space 4096 > > .section .ro0,"a"; .byte 255 > .section .nobits0,"aw",@nobits; .space 1024 > .section .ro1,"a"; .byte 255 > .section .nobits1,"aw",@nobits; .space 4096 > > #--- a.lds > SECTIONS { .ro0 : {} .nobits0 : {} .ro1 : {} .nobits1 : {} } INSERT AFTER .bss; > ``` > > ```sh > split-file a.txt a > path/to/musl-gcc -Wl,--dynamic-linker=/lib/libc.so a/a.c a/a.lds -o toy > ``` > > split-file is a utility in llvm-project. Where is a.txt? Also, it'd be nice to have this without needing the musl-gcc.
On 2022-11-11, Kees Cook wrote: >On Thu, Nov 10, 2022 at 11:42:34PM -0800, Fangrui Song wrote: >> (+ sam@gentoo.org from Pedro Falcato's patch) >> >> On 2022-11-10, Kees Cook wrote: >> > Traditionally, only the final PT_LOAD for load_elf_interp() supported >> > having p_memsz > p_filesz. Recently, lld's construction of musl's >> > libc.so on PowerPC64 started having two PT_LOAD program headers with >> > p_memsz > p_filesz. >> > >> > As the least invasive change possible, check for p_memsz > p_filesz for >> > each PT_LOAD in load_elf_interp. >> > >> > Reported-by: Rich Felker <dalias@libc.org> >> > Link: https://maskray.me/blog/2022-11-05-lld-musl-powerpc64 >> > Cc: Pedro Falcato <pedro.falcato@gmail.com> >> > Cc: Fangrui Song <maskray@google.com> >> > Cc: Alexander Viro <viro@zeniv.linux.org.uk> >> > Cc: Eric Biederman <ebiederm@xmission.com> >> > Cc: linux-fsdevel@vger.kernel.org >> > Cc: linux-mm@kvack.org >> > Signed-off-by: Kees Cook <keescook@chromium.org> >> > --- >> > v2: I realized we need to retain the final padding call. >> > v1: https://lore.kernel.org/linux-hardening/20221111055747.never.202-kees@kernel.org/ >> > --- >> > fs/binfmt_elf.c | 18 ++++++++++++++---- >> > 1 file changed, 14 insertions(+), 4 deletions(-) >> > >> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c >> > index 528e2ac8931f..0a24bbbef1d6 100644 >> > --- a/fs/binfmt_elf.c >> > +++ b/fs/binfmt_elf.c >> > @@ -673,15 +673,25 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex, >> > last_bss = k; >> > bss_prot = elf_prot; >> > } >> > + >> > + /* >> > + * Clear any p_memsz > p_filesz area up to the end >> > + * of the page to wipe anything left over from the >> > + * loaded file contents. >> > + */ >> > + if (last_bss > elf_bss && padzero(elf_bss)) >> >> Missing { >> >> But after fixing this, I get a musl ld.so error. >> >> > + error = -EFAULT; >> > + goto out; >> > + } >> > } >> > } >> > >> > /* >> > - * Now fill out the bss section: first pad the last page from >> > - * the file up to the page boundary, and zero it from elf_bss >> > - * up to the end of the page. >> > + * Finally, pad the last page from the file up to the page boundary, >> > + * and zero it from elf_bss up to the end of the page, if this did >> > + * not already happen with the last PT_LOAD. >> > */ >> > - if (padzero(elf_bss)) { >> > + if (last_bss == elf_bss && padzero(elf_bss)) { >> > error = -EFAULT; >> > goto out; >> > } >> > -- >> > 2.34.1 >> > >> >> I added a new section to https://maskray.me/blog/2022-11-05-lld-musl-powerpc64 >> Copying here: >> >> To test that the kernel ELF loader can handle more RW `PT_LOAD` program headers, we can create an executable with more RW `PT_LOAD` program headers with `p_filesz < p_memsz`. >> We can place a read-only section after `.bss` followed by a `SHT_NOBITS` `SHF_ALLOC|SHF_WRITE` section. The read-only section will form a read-only `PT_LOAD` while the RW section will form a RW `PT_LOAD`. >> >> ```text >> #--- a.c >> #include <assert.h> >> #include <stdio.h> >> >> extern const char toc[]; >> char nobits0[0] __attribute__((section(".nobits0"))); >> char nobits1[0] __attribute__((section(".nobits1"))); >> >> int main(void) { >> assert(toc[4096-1] == 0); >> for (int i = 0; i < 1024; i++) >> assert(nobits0[i] == 0); >> nobits0[0] = nobits0[1024-1] = 1; >> for (int i = 0; i < 4096; i++) >> assert(nobits1[i] == 0); >> nobits1[0] = nobits1[4096-1] = 1; >> >> puts("hello"); >> } >> >> #--- toc.s >> .section .toc,"aw",@nobits >> .globl toc >> toc: >> .space 4096 >> >> .section .ro0,"a"; .byte 255 >> .section .nobits0,"aw",@nobits; .space 1024 >> .section .ro1,"a"; .byte 255 >> .section .nobits1,"aw",@nobits; .space 4096 >> >> #--- a.lds >> SECTIONS { .ro0 : {} .nobits0 : {} .ro1 : {} .nobits1 : {} } INSERT AFTER .bss; >> ``` >> >> ```sh >> split-file a.txt a >> path/to/musl-gcc -Wl,--dynamic-linker=/lib/libc.so a/a.c a/a.lds -o toy >> ``` >> >> split-file is a utility in llvm-project. > >Where is a.txt? Also, it'd be nice to have this without needing the >musl-gcc. Sorry for the unclear description. I rewrite it. (`char nobits0[0] __attribute__((section(".nobits0")));` is not effective. It's SHT_PROGBITS and makes the output section SHT_PROGBITS. The new example addresses the deficiency.) Create some files. If you have split-file (a [test utility](https://llvm.org/docs/TestingGuide.html#extra-files) from llvm-project), you may place the following content into `a.txt`. ```text #--- a.c #include <assert.h> #include <stdio.h> extern const char toc[]; extern char nobits0[], nobits1[]; int main(void) { assert(toc[4096-1] == 0); for (int i = 0; i < 1024; i++) { assert(nobits0[i] == 0); nobits0[i] = 1; } for (int i = 0; i < 8192; i++) { assert(nobits1[i] == 0); nobits1[i] = 1; } puts("hello"); } #--- toc.s .globl toc, nobits0, nobits1 .section .toc,"aw",@nobits; toc: .space 4096 .section .ro0,"a"; .byte 255 .section .nobits0,"aw",@nobits; nobits0: .space 1024 .section .ro1,"a"; .byte 255 .section .nobits1,"aw",@nobits; nobits1: .space 8192 #--- a.lds SECTIONS { .ro0 : {} .nobits0 : {} .ro1 : {} .nobits1 : {} } INSERT AFTER .bss; ``` Then run: ```sh split-file a.txt a path/to/musl-gcc -Wl,--dynamic-linker=/lib/libc.so a/a.c a/a.lds -o toy ``` Note: when a `SHT_NOBITS` section is followed by another section, the `SHT_NOBITS` section behaves as if it occupies the file offset range. This is because ld.lld does not implement a file size optimization. For this simple example, using glibc based gcc works as well (musl provides __assert_fail and puts referenced by the executable): gcc -Wl,--dynamic-linker=/lib/libc.so a/a.c a/a.lds -o toy
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 528e2ac8931f..0a24bbbef1d6 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -673,15 +673,25 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex, last_bss = k; bss_prot = elf_prot; } + + /* + * Clear any p_memsz > p_filesz area up to the end + * of the page to wipe anything left over from the + * loaded file contents. + */ + if (last_bss > elf_bss && padzero(elf_bss)) + error = -EFAULT; + goto out; + } } } /* - * Now fill out the bss section: first pad the last page from - * the file up to the page boundary, and zero it from elf_bss - * up to the end of the page. + * Finally, pad the last page from the file up to the page boundary, + * and zero it from elf_bss up to the end of the page, if this did + * not already happen with the last PT_LOAD. */ - if (padzero(elf_bss)) { + if (last_bss == elf_bss && padzero(elf_bss)) { error = -EFAULT; goto out; }