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 41F4DC369D1 for ; Fri, 25 Apr 2025 12:41:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98EEC6B0005; Fri, 25 Apr 2025 08:41:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93BC46B0006; Fri, 25 Apr 2025 08:41:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 836476B0007; Fri, 25 Apr 2025 08:41:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 66E426B0005 for ; Fri, 25 Apr 2025 08:41:40 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 670CBC1097 for ; Fri, 25 Apr 2025 12:41:37 +0000 (UTC) X-FDA: 83372527434.21.0F6E793 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 5946380005 for ; Fri, 25 Apr 2025 12:41:35 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745584895; a=rsa-sha256; cv=none; b=Iu/22kep0MbgwCO5B5F6tWprvy3jD5vt6l2CRbIwlxliU3g4Y5gf+gMLYfAeBhinhTtFRm UAQ/ZUuNE/0hPv9bNY9qHs3/FXpMuhfM124RSCnGysmtzsRhF9+2xzJsWD3K3B1a4mmNMI 69Qpd8zlCU05asjJZQmitDY4n+c1GUY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745584895; 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: references; bh=cLkf8WACstYTJxddueeqYJMP2WjUmq1R4SoKNA2QWwg=; b=5mCx8q38VaE1k3G8vm6n+o5TH17Sf00Xp8PT17PSXkFlJlODLcm3aRYjNd4/vM3RvbFK9Z W09Y/Mx3y44DrGqEgA6/hbAoNzshooK5dms4QjsSwIl7UftOpIGFgQgIf9LsXE9+ntnddM JeMbTIS32zAnxhrQYYzyi+3sFD+A1/Y= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C7016106F; Fri, 25 Apr 2025 05:41:28 -0700 (PDT) Received: from [10.57.90.155] (unknown [10.57.90.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 40D123F66E; Fri, 25 Apr 2025 05:41:33 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2025 13:41:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB From: Ryan Roberts Cc: Linux Kernel Mailing List , Linux-MM , "linux-arm-kernel@lists.infradead.org" To: Kees Cook , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Catalin Marinas Subject: BUG: vdso changes expose elf mapping issue Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5946380005 X-Stat-Signature: g7bou735dp6z1rn8p5uibqjpetp9wjid X-Rspam-User: X-HE-Tag: 1745584895-669657 X-HE-Meta: U2FsdGVkX1++MEO5GOIO9GsWHP4/BMdUxrVegk2Qo+ogfhy+iiJM1mwPqfjkKQOypCR+TBSucs5tFyQBoy2TNOfwMp+buWUGtZYndy2AeoSRMx3jPc7J5TpZUAOnBh5KldoysFRekS1j8SnLiFRYy417o8RWus7/V5zDn/5CruEOHRQ9bORh7Gp5lEFqu6huQXQS4sOetc8fBx/hsXtyLEgrcpsAm6xILjpUdpHlCE2JciCw3aB8T16GADQZgYKss6XG4iuKXqMGsq+h+cM8PeBjV1sjCnYikjrcXYiflD56efKDqPjrRmgPx4axqd6Kh2WXE20DStbsha6WK6kc/uhh3DNtwHeBn5hl4ZZXl8T2b+QUsJZ4sgl9mtwzYqFVSFEKVlap1MXeVE/1R8z6nX4EeJEKARMCosB9b5YT6e4NrJT7ldIMWrNse7D8WZiFd720BeB5FteA6M0jVuZ+z3ipeAOiZUeiOX+f1uqBuS/uDxslFr32qNT82sZjb2lKhARBeH8MelZpdCO01qLIZ4RVwpGm3ixt1aWm1QoRhYEAO14GBLb/QhR37biWy9voMsiVS96kRKX24HowYYIIm8BxAELQw36VKhMYtsCAVdzaAkJ2rP9iJEDzxgGk1xsM6qVO/O0O+Qca1PHP9iAtlrW1JpsYgxPJ9asw79MFYS32blX8A1/wB4mLt1ESkIpWNi6UbawXzCceWFP4Z4J1TqWO/x/8yvRwrcGtoF/tfL5omuGwJLaNyXWM4eeKgSemQaHd9PgcU+oojTuCgQGB0u8Uc2/Z8PzT2a4qlUlM7n/J6541zPNmfiTcV9Gp/pzDkvx2QOMLrdpJfsnxaRW9Imq7x6EnqxFbDaAEDlQb8bh0tgDd1sh1PJJjLavDi5GMm8YkZr3eVAT/Mpb/9xDXvZHaZkH1vnksle+UVYlYS7CPr00+trqLOFvBV6xWg3pcT0JQyCrX6cRzziMRwUT Z7QA8RjR Mz3FrAkdlKzKyz+XG6Yj1TqgaJZ6bsDnblcTAx8RKM5x4PwxWNr+xxGaGe3LD0WmndOiv9iHqy2DYV3IYZIPtPuOCYk30FaYIAohOHAKazciOglVrwrGXQszvTqlu8SsG94vlphitXp8wZO/s+vwx9u1B+eQa5i6K+cEgXzSPdZaxZ+denjnU0d/9zQ== 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: List-Subscribe: List-Unsubscribe: Hi, I'm hitting a nasty bug which is preventing VSCode from connecting to my arm64 VM running v6.15-rc3. Bisection fingers Commit 0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation") as the point where this started failing. Debugging this, the root cause is due to ldconfig crashing with a segmentation fault (I have no idea why VSCode thinks it needs to run this...). The segfault happens because ldconfig's attempt to expand the program break fails because vvar/vdso are in the way. The above change expands vvar by 2 pages and this causes the problem. But I don't think we can really blame this commit... ldconfig is a statically linked, PIE executable. The kernel treats this as an interpreter and therefore does not map it into low memory but instead maps it into high memory using mmap() (mmap is top-down on arm64). Once it's mapped, vvar/vdso gets mapped and fills the hole right at the top that is left due to ldconfig's alignment requirements. Before the above change, there were 2 pages free between the end of the data segment and vvar; this was enough for ldconfig to get it's required memory with brk(). But after the change there is no space: Before: fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /home/ubuntu/glibc-2.35/build/elf/ldconfig fffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /home/ubuntu/glibc-2.35/build/elf/ldconfig fffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0 fffff7ffc000-fffff7ffe000 r--p 00000000 00:00 0 [vvar] fffff7ffe000-fffff8000000 r-xp 00000000 00:00 0 [vdso] fffffffdf000-1000000000000 rw-p 00000000 00:00 0 [stack] After: fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /home/ubuntu/glibc-2.35/build/elf/ldconfig fffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /home/ubuntu/glibc-2.35/build/elf/ldconfig fffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0 fffff7ffa000-fffff7ffe000 r--p 00000000 00:00 0 [vvar] fffff7ffe000-fffff8000000 r-xp 00000000 00:00 0 [vdso] fffffffdf000-1000000000000 rw-p 00000000 00:00 0 [stack] Note that this issue only occurs with ASLR disabled. When ASLR is enabled, the brk region is setup in the low memory region that would normally be used by primary executable. So the issue is that when ASLR is disabled, these statically linked, PIE programs are mapped with insufficient space to expand the break. I think in an ideal world, the kernel would notice that this is not an interpreter and map it to low memory. But I guess we can't know that for the case where the interpreter is invoked directly (as apposed to being referenced in the .interp section of the invoked binary)? Another option would be to always relocate the break to low memory (but without the random offset for the ASLR=off case). But it looks like there could be some compat issues there? I see CONFIG_COMPAT_BRK... Or we could just ensure we enforce some dead space after the end of the program that nothing else is (initially) mapped into. I think this could be done by overallocating the initial MAP_FIXED_NOREPLACE mmap, then munmapping the hole after ARCH_SETUP_ADDITIONAL_PAGES(). But it's not really clear what the correct reservation size would be, and any mmaps the program does will start to fill that space. I'm hoping someone has some suggestions... Thanks, Ryan