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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 691EAEEAA6B for ; Thu, 14 Sep 2023 19:50:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F6508D001E; Thu, 14 Sep 2023 15:50:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A6578D0001; Thu, 14 Sep 2023 15:50:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76E788D001E; Thu, 14 Sep 2023 15:50:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 672018D0001 for ; Thu, 14 Sep 2023 15:50:19 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2E05F805B5 for ; Thu, 14 Sep 2023 19:50:19 +0000 (UTC) X-FDA: 81236244558.18.D29CA92 Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by imf09.hostedemail.com (Postfix) with ESMTP id 96DA3140026 for ; Thu, 14 Sep 2023 19:50:16 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.232 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694721016; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p26gYOVDwodYiYj84qXi8tV15pozn0ehjAN4cy4fhTs=; b=MBaSqd2IW6HYXw0BZcNOsC/2zOXniOoQ5Q9WIMI/o/iTWZ7qYmzrLIz1jdRCuzVHw7x/0d vmY/pmrlhw9gzW6lM0b8ZzWGHuVdRWPM6DXRgCYnXchtlAu4ciIUAWW8V79qqXq3dnxa3/ kaFOVIOkzodwmYBJtutIX4xmLmngCfA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694721016; a=rsa-sha256; cv=none; b=o9MvV3cUriU7aCxxNd9+0wYpt1i5tjdbBTkxxz5lEkh6Fy+PAomTyfHgUWGjpU819aEk2I B7xWjxy9kv6MoEDBUhLt3qlKUPmX4OFyiGnd2kRJYpWFUlE5tGTNlGnFqWan3puEB8Y0mT QLbxSw/4d6kFS+zIpM0salr90/gpzdY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.232 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com Received: from in02.mta.xmission.com ([166.70.13.52]:38982) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qgsLn-00GZhg-4r; Thu, 14 Sep 2023 13:50:07 -0600 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:33022 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qgsLl-003z6W-RZ; Thu, 14 Sep 2023 13:50:06 -0600 From: "Eric W. Biederman" To: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Cc: Alexander Viro , Christian Brauner , Kees Cook , Mark Brown , Willy Tarreau , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sebastian Ott , stable@vger.kernel.org References: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net> Date: Thu, 14 Sep 2023 14:49:44 -0500 In-Reply-To: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net> ("Thomas =?utf-8?Q?Wei=C3=9Fschuh=22's?= message of "Thu, 14 Sep 2023 17:59:21 +0200") Message-ID: <87fs3gwn53.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1qgsLl-003z6W-RZ;;;mid=<87fs3gwn53.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18h1j36igoeR9FeBDXb/u1JtAQea+Mzym8= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Stat-Signature: uupeaywcsurpanors9mgswdnfdyqa1uo X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 96DA3140026 X-Rspam-User: X-HE-Tag: 1694721016-483479 X-HE-Meta: U2FsdGVkX1+3grD5WPMw1zFEpnqosWZGnesvwHnsW/r4gfbXNjb0kbB98ZKiSkOmS3MSLOCZztfuDzhfCkejEH5w4yWAl1S9jHTanaScpDRci1/IPH41hDkzjNHHinMFsDBIBfW+coHCsxTWy0qYZvfLLbNSK9RWHD4Nh1AhKtAl45F52fgRz3GrmCQfJ6x6GcCYJhiiMZsbwoLwrTIVQ2N1NGaIEVOV0mzoNgY8LSHDOtKMpFBHiEYRDPAmksssIYjy/gmFlQoqoYI49YajSENTak44OrD2Zg7GAzsnqfGGgcrx/haMND5Eml11r0SPfPKRFSMZJCdqzHbmR9/NjgWNA2o+sjgbBQKy0XIwVti7OL71dL0ORJNt6yhbxCCR6Q7zn0V6EHEDzx5LhTRXRLLljlsEgJ5nUSA8YBRhxagOVBla26U2jzfUwhmQebKcH2i4fkkglMzdaNGktTaMeXKjZ5nzhnyxAZgkk8xaWEubCubGv0Rn4TMrmx04mSjAkw7ju7KFeKxF4yJaTbT4Gb+LmrwoVaheYD6CJNXfAPEEHodfW1bXXURI47tpeBvGGw0waKhHI+q5E0GBesBtaZygRTwZvPy3BRjYHC060lc9enGonhof5J+THQN1qIWzjFRpNaDvQRrjaJ9GJuzwAOjFLuuVTdeGBBuFC98s9nselZ+R2k7WEogvA27JV2VzXU0dDNFcb9Dsr+v6vfTf3Vg+zSpSfxDslnZSSjli0D0XZc5pIqM40psPRsn+rJBMQu406jjvdznSgKDQBTwu8fIF+IOlMaEMfjPKD3Dir6RQQY+aVVEkb3vmMc6/Gb3bXbC8DhsaJMsqnkceEYLr9SpqQXbPZZy4mXJWx1+y012Kcg3U6P41cnT5mRkxeqeUUmWUIQEuzkrmLocBas/JrZVQS6C9R11Q6nqBvfBu4+ykDE1c9655aoOr8gKhq1mP41/7ztocNAjrrY8tx95 HExolGtC 01ey35Iqd7dC4t/bfp623DRqz7irtUWiiRXFOsa8bvYiF9jC+w70teKZ0FZJmW7yso3VKmcgDvfrbe+3s3k2fh6PAOdXLpdRrcnVxHQckFVFPHzl7zH8KXbPgKYxdNdSdc3cxhEVlNmvj6QGMqNb8Obvc9UHvqm5g0pUE6w7av1kLkOKmevWcD4T00CVEKYF0xLC09uHrICEnKWAq458KCUqT09BuuHSzRQUgXjl1FbCPRmAnh/Bnbzd4QdKdD3M0vJKZLMRRJvJQ/iSLxQhvFHv4uLSW2oGn44aRKFv1SLkjRA88Jguj8hN3bRB7gn7ryotv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Thomas Wei=C3=9Fschuh writes: > When allocating the pages for bss the start address needs to be rounded > down instead of up. > Otherwise the start of the bss segment may be unmapped. > > The was reported to happen on Aarch64: Those program headers you quote look corrupt. The address 0x41ffe8 is not 0x10000 aligned. I don't think anything in the elf specification allows that. The most common way to have bss is for a elf segment to have a larger memsize than filesize. In which case rounding up is the correct way to handle things. We definitely need to verify the appended bss case works, before taking this patch, or we will get random application failures because parts of the data segment are being zeroed, or the binaries won't load because the bss won't be able to map over the initialized data. The note segment living at a conflicting virtual address also looks suspicious. It is probably harmless, as note segments are not loaded. Are you by any chance using an experimental linker? In general every segment in an elf executable needs to be aligned to the SYSVABI's architecture page size. I think that is 64k on ARM. Which it looks like the linker tried to implement by setting the alignment to 0x10000, and then ignored by putting a byte offset beginning to the page. At a minimum someone needs to sort through what the elf specification says needs to happen is a weird case like this where the start address of a load segment does not match the alignment of the segment. To see how common this is I looked at a binary known to be working, and my /usr/bin/ls binary has one segment that has one of these unaligned starts as well. So it must be defined to work somewhere but I need to see the definition to even have a good opinion on the nonsense of saying an unaligned value should be aligned. All I know is that we need to limit our support to what memory mapping pieces from the elf executable can support. Which at a minimum requires: virt_addr % ELF_MIN_ALIGN =3D=3D file_offset % ELF_MIN_ALIGN Eric > Memory allocated by set_brk(): > Before: start=3D0x420000 end=3D0x420000 > After: start=3D0x41f000 end=3D0x420000 > > The triggering binary looks like this: > > Elf file type is EXEC (Executable file) > Entry point 0x400144 > There are 4 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000400000 0x000000000040= 0000 > 0x0000000000000178 0x0000000000000178 R E 0x10000 > LOAD 0x000000000000ffe8 0x000000000041ffe8 0x000000000041= ffe8 > 0x0000000000000000 0x0000000000000008 RW 0x10000 > NOTE 0x0000000000000120 0x0000000000400120 0x000000000040= 0120 > 0x0000000000000024 0x0000000000000024 R 0x4 > GNU_STACK 0x0000000000000000 0x0000000000000000 0x000000000000= 0000 > 0x0000000000000000 0x0000000000000000 RW 0x10 > > Section to Segment mapping: > Segment Sections... > 00 .note.gnu.build-id .text .eh_frame > 01 .bss > 02 .note.gnu.build-id > 03 > > Reported-by: Sebastian Ott > Closes: https://lore.kernel.org/lkml/5d49767a-fbdc-fbe7-5fb2-d99ece3168cb= @redhat.com/ > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org > Signed-off-by: Thomas Wei=C3=9Fschuh > --- > > I'm not really familiar with the ELF loading process, so putting this > out as RFC. > > A example binary compiled with aarch64-linux-gnu-gcc 13.2.0 is available > at https://test.t-8ch.de/binfmt-bss-repro.bin > --- > fs/binfmt_elf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 7b3d2d491407..4008a57d388b 100644 > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -112,7 +112,7 @@ static struct linux_binfmt elf_format =3D { >=20=20 > static int set_brk(unsigned long start, unsigned long end, int prot) > { > - start =3D ELF_PAGEALIGN(start); > + start =3D ELF_PAGESTART(start); > end =3D ELF_PAGEALIGN(end); > if (end > start) { > /* > > --- > base-commit: aed8aee11130a954356200afa3f1b8753e8a9482 > change-id: 20230914-bss-alloc-f523fa61718c > > Best regards,