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 E2914C3ABA3 for ; Fri, 2 May 2025 10:34:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14B7D6B0088; Fri, 2 May 2025 06:34:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D4906B0089; Fri, 2 May 2025 06:34:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB59E6B008A; Fri, 2 May 2025 06:34:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CB26E6B0088 for ; Fri, 2 May 2025 06:34:10 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 759C41A13C2 for ; Fri, 2 May 2025 10:34:11 +0000 (UTC) X-FDA: 83397607902.17.9761F29 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf09.hostedemail.com (Postfix) with ESMTP id A8907140008 for ; Fri, 2 May 2025 10:34:09 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf09.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=1746182049; 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=Wp4rdlPEifcuxWTWv7mbmabsclA+T0J64ozwxPFK168=; b=02OVHirNAJQ49XD47JnxXHHdkBqMSHhhXo1mn9reDDolAMzPBQt7BlMtv8zpZ84yVr7hw/ IxiEHvetUxu2eqDrNFFDMO9kf1SIFDIuMB9f/NOMRFmNAgKnRIYCLiaF8fzMI3HNQXWp/8 ewerqfgYhvPGjc4uJn/S+DXTcEskMoY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf09.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=1746182049; a=rsa-sha256; cv=none; b=npoJRMZELhhgeZJbQDvmId1ibkc2SoYYQguDLKbuM3IyOJvt285PWGIODQ4IY1Vq4x6NZR aDgvwQA8NDmxdmfEVDbpNYCSQ808I3V42oPRVSsdddtpreC9ryXPQzAS32InqvVZTe/lCs gZRr9DlJvwWeDtRNxE3Rir+VWTci4ow= 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 9E94A106F; Fri, 2 May 2025 03:34:00 -0700 (PDT) Received: from [10.57.93.118] (unknown [10.57.93.118]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB4533F66E; Fri, 2 May 2025 03:34:05 -0700 (PDT) Message-ID: Date: Fri, 2 May 2025 11:34:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] binfmt_elf: Move brk for static PIE even if ASLR disabled Content-Language: en-GB To: Kees Cook Cc: Catalin Marinas , Al Viro , Christian Brauner , Jan Kara , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Ali Saidi , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org References: <20250425224502.work.520-kees@kernel.org> <202504301207.BCE7A96@keescook> <202505011633.82A962A7@keescook> From: Ryan Roberts In-Reply-To: <202505011633.82A962A7@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A8907140008 X-Stat-Signature: opt3ou4du3p1dmw4qy4mt7we55ekt6zd X-HE-Tag: 1746182049-472584 X-HE-Meta: U2FsdGVkX1+Qd+BfWNQdFXs5vuUs63jtjEDFGQu1M0sTUOBudEJ/zCTP/M29rRZf6wLK5lfJ91z2I+cKL/FEVwDkn+zF6yNXMsGNzqzTERZp11TnhelJyKdZ3AihMfHVD7wd9Z4KYdFEkV/Cg825ZHC4lLd6aMJq9r33YlKs44dO1uJcfSun0/9GoAEuBctUoYJau2mOhTU52gnVDXYdKNiGHW4eNfRHn+dvDR3sdqhdtFj05U8FrfXhsiqo7mpjXaFl0KXljLLCZsJ2ddS2LezOc9h8tOejiLinlVABe1rDc6+aDISWEbBdc82vQ2GAiWs7Mk5nt28oXYun0q3FPS56yZjV6EcHyowIEGwZXUswme+K9NNT4aXGfOGObBdoOxSOl3XBpJ6elok+nzxVEmt62XKR7xwudCHPmbh6hhRo5iJly7nwfe0lmJdC51GgxjIQGz8g8P9wrTWAxhxARiAcNBiYh5ZHd6oaQxGJGUTCHOAw9lkxJ4yPIV5N5szNVbvKtnqq2KoTXx6B+XTtA6CHqRbkDG01m4486EIb7D7f26E0MPbUAR3XdF1lx98rBZX+sDQUxNDyd8//SuWIThR1N7Y+llWNyUL34+PEe7+syiCVd7lTrirISaX6CNao+K1K5f9qfVVvzb2WAolFHo8vCFHOnCaZFMXj/oC4yz0SzTQrgVon3Qh2VhRY2xbPx31re7+mAi69ufBBcY3TnysXAQ9e6U+2I97Hyec20HxU5vZM5jWPGn/fuAino0lHbzeKD0ch7/8kLNgUDiDgB0yrU++Z4cLwwWcihOarZffVUXVo4g4nevWILT6JPlgBYldgvZzoL6Uu7uBBbogACj/L5ALz1jg1jWGZKT7mhwjvhgs0QjMpOkNc95ZHmlp9ellniJ4JWhOdFfXQY6NOSlDBmJY7llzbLN1Ygh/SCufcy2V2rmEct9pFshaLTVCGUUvPzC73cbcApyLeTT1 MH36agJz +kEYiip94V2lRUsFyMrR+zwr82ih/rdUjCHFsxl6VwbWQXFOtT5k8gPCxgBKqX5lD4y/ZLtW4kcJqtbrAv6q4/FuOTa62Xo11ww4pNS4k81mVC/A/zmJh/gMpRcmksyU8zNX9fYH27BlzOJqVsaZED3VVARiKXIPV2xdTfLzv3p0cE5kXDKsPgbhQxQwnYIXtLshE 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 02/05/2025 00:49, Kees Cook wrote: > On Thu, May 01, 2025 at 12:03:32PM +0100, Ryan Roberts wrote: >> I agree, as long as COMPAT_BRK is not set (which is the common case IFAICT). >> When COMPAT_BRK is enabled, I think you are breaking the purpose of that >> Kconfig? Perhaps it's not a real-world problem though... > > When you turned off ASLR, what mechanism did you use? Personality or > randomize_va_space=0? randomize_va_space=0 > >>> It's possible it could break running the loader directly against some >>> libc5-based binaries. If this turns out to be a real-world issue, we can >>> find a better solution (perhaps pre-allocating a large brk). >> >> But how large is large enough... > > Right -- Chrome has a 500MB brk on my laptop. :P Or with randomization > off, it could allocate to the top of the mmap space just to keep > "future" mmap allocations from landing in any holes... > >> Perhaps it is safer to only move the brk if !IS_ENABLED(CONFIG_COMPAT_BRK) ? >> Then wait to see if there are any real-world COMPAT_BRK users that hit the issue? > > Yeah, that might be the best middle-ground. >