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 0BB1FC3ABC9 for ; Tue, 13 May 2025 09:19:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BC4E6B000A; Tue, 13 May 2025 05:19:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 56A016B0083; Tue, 13 May 2025 05:19:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47F7D6B0085; Tue, 13 May 2025 05:19:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2B07F6B000A for ; Tue, 13 May 2025 05:19:45 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AF75EC031C for ; Tue, 13 May 2025 09:19:46 +0000 (UTC) X-FDA: 83437337172.09.9F38AB5 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf19.hostedemail.com (Postfix) with ESMTP id 8CFFC1A0008 for ; Tue, 13 May 2025 09:19:44 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747127985; 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=A41QkyzhyCRx+iXbPHodlj6RuxUdcAln7pFCaZS4Hw4=; b=P+OOlaGzzXKLqEZ3DjWtTDqet59QFS7bdvLPy2mxdOkpV4GG90AMa360Q5ro4rOq2zii1/ dBXvZzLX7O4VgIcYi+aIbpBZF5vSLKoyisABJe92w5C0eKJtk59Rn+UJrk3nVIXdm1meeh RY8WR94M8rTQefJMK0fyBlUG7bhjeZM= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747127985; a=rsa-sha256; cv=none; b=En1OQHKLfrjBWmkL6DPDu/7o2nqyglDjLcbrkqgFrh/13o8UCf0cN1SpA9TDg/03KBJ5bH mbt+qCd3yorxMbg+ineuIyl0jeLyq2YA0xTF/e6osppEVuefpocdA5xqOrgMWr8a52O2Dg 8L+SoWTK6dRntdydASb9XZbFaAhO3nE= 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 A0522168F; Tue, 13 May 2025 02:19:32 -0700 (PDT) Received: from [10.57.90.222] (unknown [10.57.90.222]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09E603F673; Tue, 13 May 2025 02:19:41 -0700 (PDT) Message-ID: <56655ac1-a650-43d8-8080-a03c250474d3@arm.com> Date: Tue, 13 May 2025 10:19:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] binfmt_elf: Move brk for static PIE even if ASLR disabled Content-Language: en-GB To: Kees Cook 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 References: <20250502001820.it.026-kees@kernel.org> <87f80506-eeb3-4848-adc9-8a030b5f4136@arm.com> <202505121340.7CA14D4C@keescook> From: Ryan Roberts In-Reply-To: <202505121340.7CA14D4C@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 8CFFC1A0008 X-Rspamd-Server: rspam09 X-Stat-Signature: uj5p5rhe9ejjtkpkehaknysg7xssymij X-HE-Tag: 1747127984-614821 X-HE-Meta: U2FsdGVkX19Vli/1+vOs8tWuxCzO+XveEVsCn4gprneRiqzPLBuROVzA8ZLLPPYsF5tHMICBUtDilchEmUWK+roIfmoLz9TUpUVA3C3tM+qJhBI4PPX3zu7KRQqu9vXdaMaJKoD7C2LcVrQmPhL/1R6e2tZZWctuUXnaEwDQER/vR2NIwmequhybnhV0k/Zpwxy5cWVuZfYUg7C+71P2XuUetyiUQzoMH1EUbzOTsU7jGptsMCrrjZRcyZ7Ku8uWPbzB2JrqnJQH2+UAL9GTfhKiVrgZUl3hCSa/QMAlnfdSFPB6Rl8uMs9c2p+/HeFFlYGIXAysYdpjy/qXyaejjlbNdZyP5aQ2SSgcpvHxxud5qkGOGtKGxcM+wucs0Ki+22I57+uE3FO46feNaHGLLLn27uz5Igp2lfeMxPOrCCe/hEsqaa5ESq3tzleCEorbutDKydKDjgbmUJOMvKqQe9AuH2HHTXohWs0olIU1tR5sM/zULeLOX6Fmt+lMSc/SwXpDbBJDx7AngJV9IK3e+S5SFiyRVn9gFD074sRzNr1YHaO+VXQTUjDXhYSOrlpispcmyYz0TMJ/EdmKx2eQqDok9/tio6XitkisADQHGfP1BVPZ2JbbK4mWL8vpkPY1YhHTlHntoqUWP0s/dZAmrjjIendTzMUY/SomuDqutTHItdj8dypp1A/PIlY6t0gHHqbrleiKQY+52I+8FE5P4W1gpsLKbmCokkvo1q5AWvkyIlhuwDihzkxWGhAKLC/mJu0MoITz7WjeleWjJ9xyYWfQnnNze/n3UXKYIH1MQPXddZxok2SwdMsLqt0RBuJ4RZyyl7tNRuzylARd/ANFvpN6yECbg16+RmRLN64uWAUP0RK1tcXr456V1lT4pL+jjPimF3svwf+zzEXxrLOn+XmM5v+Fe4ZLDKKFeR/6+TALy8pMDffF4uP4iWaaGYrLkh59LPKuaDux443J8xL wRmfnZsJ 18u3CmwI8rgnrp8Z/KENOJinXtiHsPrQcwoI5p4tpfe3D3v3fMlxZt+BsGWXWMzEWNbKhvJDTYA2+w4Ww6eLFdyvXX5Eth37R+HDbyfnt/ec0zn/mTNrb1wijGEYHnbvtvGvSlyoTYUxnpftEGHDuXVuHTPODpHyEB9fvszfiIdRQPI9FLzw4uO7VwIXrBDyQbBKh 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 12/05/2025 21:40, Kees Cook wrote: > 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. Sorry, Kees - my bad! For some reason, I thought this would go via the mm tree. Thanks again for jumping on this.