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 8FCCCC369C2 for ; Fri, 25 Apr 2025 18:37:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 866CE6B000E; Fri, 25 Apr 2025 14:37:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8181C6B0010; Fri, 25 Apr 2025 14:37:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 705AA6B0011; Fri, 25 Apr 2025 14:37:45 -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 5419A6B000E for ; Fri, 25 Apr 2025 14:37:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 22C1D1605E2 for ; Fri, 25 Apr 2025 18:37:46 +0000 (UTC) X-FDA: 83373424932.10.4371552 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 5FB8940003 for ; Fri, 25 Apr 2025 18:37:44 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf04.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745606264; 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: in-reply-to:in-reply-to:references:references; bh=aZsY0a6nrOQltQeu1yw8cksiWMQy5LuF97NOwHPYedw=; b=qMbF0AIi4twSMAOthOMS+NfFIhRgCxbCNOWK1IxDGnlT5w2K+vU6+P3ElQCNAklirohnH0 p8FKQ/cFzMl/po36gI8Tn3v+lsTAmXvcDEqEPjJGD/qiaQd+adfFLhCUjaCkYE1zMeHYAC l3/IGIYm++QGg5/YjPrOcOxzNtWWsEY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745606264; a=rsa-sha256; cv=none; b=DvZNXWz5qE7Zugdl+c/Jdq02pCuejptjfa8qPc8A+mR1ktTOiajZk4LsjiKlGIkZDQDsjI DJDrF+upNSNhVWeMhA6qr1dfgMmldzRMoxBZ2JjAdIyHN+ypgv1iZNVYLDyZa4R1n8ciDz L3bOwYXlS9CnCFRhIY+lffxUNaPtZAI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf04.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 599BA5C6AAB; Fri, 25 Apr 2025 18:35:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F30F3C4CEE4; Fri, 25 Apr 2025 18:37:41 +0000 (UTC) Date: Fri, 25 Apr 2025 19:37:38 +0100 From: Catalin Marinas To: Ryan Roberts Cc: Kees Cook , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Linux Kernel Mailing List , Linux-MM , "linux-arm-kernel@lists.infradead.org" Subject: Re: BUG: vdso changes expose elf mapping issue Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 5FB8940003 X-Rspam-User: X-Stat-Signature: jjxeba5gxsherbzmup9d41o5bfz91u4q X-HE-Tag: 1745606264-918111 X-HE-Meta: U2FsdGVkX18uOMfsNVtM0ATidaAFCBftVO1rhlD63rid8FL4j4e+pUq/0T1FaNlLDVUSScC4YCAcmpGKZHCI+YzzKXz27lakZ9IjP4s1/a565FlUIjbH1uOZ3IZeOwb1dLUNTK8FHICiZUVnObkPwQNMHUPEnHVL8XQ934KN9zMKZIwgrY+ssLnBYa/aWOQ/idSV6mVRRNUIig3KY8d1NDJvs1YRqfCYzmCgoXPhdbE7EvzGFt4GxX3+vz6IYtOe7UWjZ5zajBVsXrZoHOVQ/4DV3y+MQsQbbOMM9BCH4nFCGYEYUJZg2tzPUJlHjxaokCjTJYuWf0cTa8YBiC7R7wb38RY6xHBLzzLkxH46lUZWM1Su08ehBPZvE/hLyzqDU4g0QLHSZFJVxDG8T//qaufov00Ny6hVHmaw9jt7FlXRinHkf+gn1kbf+B+BBYjVcRq43Mspm5CI1jRHlRE7ABoobfriBJ/mhzhgn0d0gvrpyhk/TZdYKPyNYpeYcqYm6jWSOO1cCrOJupmKqqoLAibi6drQxEnAUziDDvecH6oTLUxPIrpoYZbBHhxUDLFKOOuHnWEhpFTyVmQ2Ki/73JAKkMVn2gACcCy/6cg/HC1VBXgqGzCl/i9irhOFqpDUO6I/h+Dr4Pw7DOwcCcRQCI8MlFNWjRgRb/TecL57N7kO2O3154H9evCPOLdaU5ykR5n32scmd02Zbp6VmEOfhSC1eCWc/yC+DRKgOmEhmbke1C17E1R1e7xmBEDk4medn/x4kEUDXw49L7+VEI98BZx97+L1mSpRGh6zfvCWIm0BHwFa7KfBJJlgQFyjrb/Ayhcp2lpopRp/MNj7X4ZFMbsLt+PF3CdoYbYriCRv5vlNBXjTNAqjc7K+5Sf6yaFMcfrkkVysvbLO5kRIsIXoiCINbfiNNwp2qpEyInbhsgJzEel9fPiGsCghlfOQ8c4/typgjEQsK7L1VHDFL45 K052Bnnc 9r4cBGNEESjLAD5ZLiKJyeM0plga1BDmZXOG7TXlCDy2nXvlrCdSEFZm4xS3YlLuIDROAOLJtiw2pY+r/hb9yj6B9qyQj5Yuj/CwcMq0X++JEAIl5FYYwSBSYwB56M9GsbfvLgu8Y8TETMUTLjkYMXxej8JYeDVEaUm6VyAr8k2rbAZgx5uCwuY21wHlO7eMyBweMdrJECmO4v5cRJKHa8sB5LjY619bpfipRKwNrzM+LHY6RSqfnn7TvMae3J2AUXFqV1C/jXI0QFp6dRz/nM750IDsgcnsE9F5QtsrgCM5SWh4SxAyW83MLvMniSFPyuuwmBvy5C8xaf5AQsH+yshpZ1WY8+OFXnUKHLMZxitRq5jaCAjJpyEpV1/TMTFqOsTRS 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: On Fri, Apr 25, 2025 at 01:41:31PM +0100, Ryan Roberts wrote: > 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] It does look like we've just been lucky so far. An ELF file requiring a slightly larger brk (by two pages), it could fail. FWIW, briefly after commit 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE"), we got: Start Addr End Addr Size Offset Perms objfile 0xaaaaaaaa0000 0xaaaaaab5d000 0xbd000 0x0 r-xp /usr/sbin/ldconfig 0xaaaaaab6b000 0xaaaaaab73000 0x8000 0xcb000 rw-p /usr/sbin/ldconfig 0xaaaaaab73000 0xaaaaaab78000 0x5000 0x0 rw-p [heap] 0xfffff7ffd000 0xfffff7fff000 0x2000 0x0 r--p [vvar] 0xfffff7fff000 0xfffff8000000 0x1000 0x0 r-xp [vdso] 0xfffffffdf000 0x1000000000000 0x21000 0x0 rw-p [stack] This looks like a better layout to me when you load an ET_DYN file without !PT_INTERP. When the commit was reverted by aeb7923733d1 ("revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE""), we went back to: Start Addr End Addr Size Offset Perms objfile 0xfffff7f28000 0xfffff7fe5000 0xbd000 0x0 r-xp /usr/sbin/ldconfig 0xfffff7ff0000 0xfffff7ff2000 0x2000 0x0 r--p [vvar] 0xfffff7ff2000 0xfffff7ff3000 0x1000 0x0 r-xp [vdso] 0xfffff7ff3000 0xfffff7ffb000 0x8000 0xcb000 rw-p /usr/sbin/ldconfig 0xfffff7ffb000 0xfffff8000000 0x5000 0x0 rw-p [heap] 0xfffffffdf000 0x1000000000000 0x21000 0x0 rw-p [stack] With 6.15-rc3 my layout looks like Ryan's but in 5.18 above, the vdso is small enough and it's squeezed between the two ldconfig sections. Quick hack forcing the vdso alignment to SZ_64K on arm64 (not a solution, it can still fail in other ways): ------------------8<---------------------------- diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c index 78ddf6bdecad..9f9085e3e203 100644 --- a/arch/arm64/kernel/vdso.c +++ b/arch/arm64/kernel/vdso.c @@ -111,7 +111,7 @@ static int __setup_additional_pages(enum vdso_abi abi, vdso_text_len = vdso_info[abi].vdso_pages << PAGE_SHIFT; /* Be sure to map the data page */ - vdso_mapping_len = vdso_text_len + VDSO_NR_PAGES * PAGE_SIZE; + vdso_mapping_len = ALIGN(vdso_text_len + VDSO_NR_PAGES * PAGE_SIZE, SZ_64K); vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0); if (IS_ERR_VALUE(vdso_base)) { ------------------8<---------------------------- gives: Start Addr End Addr Size Offset Perms objfile 0xfffff7f10000 0xfffff7f14000 0x4000 0x0 r--p [vvar] 0xfffff7f14000 0xfffff7f16000 0x2000 0x0 r-xp [vdso] 0xfffff7f20000 0xfffff7fdd000 0xbd000 0x0 r-xp /usr/sbin/ldconfig 0xfffff7feb000 0xfffff7ff3000 0x8000 0xcb000 rw-p /usr/sbin/ldconfig 0xfffff7ff3000 0xfffff7ff8000 0x5000 0x0 rw-p 0xfffffffdf000 0x1000000000000 0x21000 0x0 rw-p [stack] Not sure what the best solution. IIUC when ld.so is loaded as an interpreter, it wouldn't need brk above its data section. However, when something like ldconfig (or ld.so) is executed directly, it should be loaded like any other ET_DYN executable at ELF_ET_DYN_BASE, e.g.: Start Addr End Addr Size Offset Perms objfile 0xaaaaaaaa0000 0xaaaaaaaab000 0xb000 0x0 r-xp /usr/bin/wc 0xaaaaaaabf000 0xaaaaaaac1000 0x2000 0xf000 rw-p /usr/bin/wc 0xfffff7fbe000 0xfffff7fe5000 0x27000 0x0 r-xp /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 0xfffff7ff6000 0xfffff7ffa000 0x4000 0x0 r--p [vvar] 0xfffff7ffa000 0xfffff7ffc000 0x2000 0x0 r-xp [vdso] 0xfffff7ffc000 0xfffff8000000 0x4000 0x2e000 rw-p /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 0xfffffffdf000 0x1000000000000 0x21000 0x0 rw-p [stack] -- Catalin