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 583D1C3ABCB for ; Mon, 12 May 2025 20:40:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDC616B0083; Mon, 12 May 2025 16:40:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8DD76B0085; Mon, 12 May 2025 16:40:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B78256B0088; Mon, 12 May 2025 16:40:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 999E86B0083 for ; Mon, 12 May 2025 16:40:48 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AB1561A04BD for ; Mon, 12 May 2025 20:40:49 +0000 (UTC) X-FDA: 83435424618.17.334BEFB Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id 0CDC640005 for ; Mon, 12 May 2025 20:40:47 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=i6m4aQvr; spf=pass (imf04.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747082448; a=rsa-sha256; cv=none; b=Pe6BgDiAI1v8E4a9VXt55A6NTmKEUX+ZRtNjl/mYpzVM2w+SPw1Pf0ZQup1qlUe2aLhJxx KGfn2rkcwoU7/JEVou/04EHup4JwznViQIZ20WNxTd80SFx83rT8r8Pt+qCRXbQeowsZPu ViL7ISIQb9mWXSjGUZW9/1ZtrJL83vE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=i6m4aQvr; spf=pass (imf04.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747082448; 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:dkim-signature; bh=7mhsKW4tAPKh3m16RhKsM3eP3QOl9RjMQhp6w2z8WdI=; b=bj0HaWze3wiG+kJLnP43bSkPzH05a1ZDs15zJZj2G1qQ0+oqmaCS6qs5Ve6XkmlHgz7P1S JAaIPGtQ7ll/I6PzTF0W39JB9sTGy7gE2709LFZ+QrIAznSfpz1ore7ZwBxtnuL/1r100B LsyK6Kf2Wquvbh7XFjTT1pRW8cTEgYs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 44F5EA4C7F7; Mon, 12 May 2025 20:40:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA003C4CEE7; Mon, 12 May 2025 20:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747082446; bh=bf5PIRNk9xJap20uZgQzAP7S5TiH/EgmMIGZvh3z444=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i6m4aQvrd6TLCpXv8P4z74bpm8a6flnmv2MsHpjztJTaUKYwJWnIR0P39740sP39M Gj1E+DeExSU8PhNNJXxDGBPl7g8z3EPtGUnRtVIWX2jQ5zbrnNRijtNcm5roFBDk37 fayuA+aMQFo8HAz2xhA3mYsI39fO+VY1T3dRl2tzlku1feXUNeAsIqRXFHPfyoAgPd BGxHei/iCuj+GuYDx40SVK24QuS+Bl0uXwCGMS4qJ9MiOTjBSnt9Y8Qb/3qjvxCETJ Nv525B5gzF76FqoPoZ7ErA6kyaW+mVukXNut5aDUiqRzUeAkTNHWdB7jsmcolmIl2Z 4C5cSv2B5zxzg== Date: Mon, 12 May 2025 13:40:44 -0700 From: Kees Cook To: Ryan Roberts Cc: Al Viro , Christian Brauner , Jan Kara , Ali Saidi , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v2] binfmt_elf: Move brk for static PIE even if ASLR disabled Message-ID: <202505121340.7CA14D4C@keescook> References: <20250502001820.it.026-kees@kernel.org> <87f80506-eeb3-4848-adc9-8a030b5f4136@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0CDC640005 X-Stat-Signature: pad5g3wfntieieze1qmgqhx9theftsx6 X-HE-Tag: 1747082447-17195 X-HE-Meta: U2FsdGVkX1/VeuvPQ3mBugFqDyDDXv7I/0eBxcekkfwJmS0l1Rv9AoYdt5jALNgz7JnG2N1m3eV34BWqwv/hqIcrmC6ilKYuv9IaGp+n85+3G2vHgz1ICN9tloN9SDjTz6laPCpGEVopEhnNVfwUDTBNDiN4Ksk0fWFoapk94uwbC91G0dUL5gUBipvEPpPasSl/ed4R0gkFG9doYiAapY9vFA+XPf/zvd/WXJcGaO++Op1Uk7Fp7UcdzClyILuHMDzhRX4Nhl5hjcDvgKmP59WZCW5uouBQ1d6R/tXgvhCrHTh+JXL5iwRt2yfDPoFeNdIj0gMWXcV2Dp0c7XCddl8PA5z04WUr6p8yhXcSm8kcoiC+LK9VfLm+anmz+IZTy904Jh5Xunv/U1x4yh+8v6G4koN//mYFVK2xtq48UufVnuMXdO02xoKp+WNpLSCYsOuV8dF1qMcdfyMvxHbeb8rtp/rDrDDi/B9un9vYhhH5mrNGNxzo+BZysl8yPzyunstapOFlhjSxJvXBiwBfjbzSSbOYmaQmu+N/h95iOFwZfrxmSPv5gZ5dC3AYlfmXxlyLvfJ2VvYs1n19Aka3K9YT9x6RkSJv3yHUBxEokrXYd0gOZFOR7toE/S7GayMV7KIJuiMeQGiOwOiCUxVnPldA5RwDzIu01LMvpCnidIeoFBp+8BsCaFIS7GTpz3gQeGhGa8+hqqAx/oK+2dDE6Lip8WCdQ+Tj1dP16CqcHQxtf0snDV7jTLMzsp4Dc7y7rjkEv0uVt8Hdn4uU+h2rum3ns6a7TOrud5yIIRFkDPW5wdW8PcPctzjjqVbhZ4b7LsxAGcBnryQflNHoltkkdn1L9ZedH1a6nopZpwBVvWnXP1+y7ib+Ohoet4s4YP4y+i8RU1w+fTxiHbFFnf+dB6Maydc98IOK2HS46kLEElJ2Nhpv2TN2/EJWbJY3o2eJA3+kur/S+5wRJf26J9f qCseaEKx KGSCvVmZXF0NOtxTwSNDfLfqKRv53xwdhKswzxYvryfDev1o0HzcCW/gcBNot40ALj5uUGFB3zfndxnxYUqOwDhlfgfAU4ma0lItLFmiRQdcv5LCSbp09wZNY6Mendj6od1ZZIvntAIbT+YHgQGqGfPhM2wPMxz+ue397eK2Ilas/zRHZTZRD9SPt5WD5PJWDB47IJOnQh3qrM33xgqjG1hnxmLIAOem6GpDXFDFbxXRpJhhUO/2fHsU55T7cQ1c7Q4UuYfDjGedmGQJl602ZVThmUFWknOI4R0cXFMqRrMYIeqs= 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 Mon, May 12, 2025 at 04:17:12PM +0100, Ryan Roberts wrote: > Hi Andrew, > > > On 02/05/2025 11:01, Ryan Roberts wrote: > > On 02/05/2025 01:18, Kees Cook wrote: > >> In commit bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing > >> direct loader exec"), the brk was moved out of the mmap region when > >> loading static PIE binaries (ET_DYN without INTERP). The common case > >> for these binaries was testing new ELF loaders, so the brk needed to > >> be away from mmap to avoid colliding with stack, future mmaps (of the > >> loader-loaded binary), etc. But this was only done when ASLR was enabled, > >> in an attempt to minimize changes to memory layouts. > >> > >> After adding support to respect alignment requirements for static PIE > >> binaries in commit 3545deff0ec7 ("binfmt_elf: Honor PT_LOAD alignment > >> for static PIE"), it became possible to have a large gap after the > >> final PT_LOAD segment and the top of the mmap region. This means that > >> future mmap allocations might go after the last PT_LOAD segment (where > >> brk might be if ASLR was disabled) instead of before them (where they > >> traditionally ended up). > >> > >> On arm64, running with ASLR disabled, Ubuntu 22.04's "ldconfig" binary, > >> a static PIE, has alignment requirements that leaves a gap large enough > >> after the last PT_LOAD segment to fit the vdso and vvar, but still leave > >> enough space for the brk (which immediately follows the last PT_LOAD > >> segment) to be allocated by the binary. > >> > >> fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /sbin/ldconfig.real > >> fffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /sbin/ldconfig.real > >> fffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0 > >> ***[brk will go here at fffff7ffa000]*** > >> 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 commit 0b3bc3354eb9 ("arm64: vdso: Switch to generic storage > >> implementation"), the arm64 vvar grew slightly, and suddenly the brk > >> collided with the allocation. > >> > >> fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /sbin/ldconfig.real > >> fffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /sbin/ldconfig.real > >> fffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0 > >> ***[oops, no room any more, vvar is at fffff7ffa000!]*** > >> 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] > > This change is fixing a pretty serious bug that appeared in v6.15-rc1 so I was > hoping it would make it into the v6.15 final release. I'm guessing mm is the > correct route in? But I don't currently see this in linus's tree or in any of > your mm- staging branches. Is there still time to get this in? I'll be sending it to Linus this week. I've been letting it bake in -next for a while just to see if anything shakes out. -- Kees Cook