From: Kees Cook <kees@kernel.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Ali Saidi <alisaidi@amazon.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] binfmt_elf: Move brk for static PIE even if ASLR disabled
Date: Thu, 1 May 2025 16:49:11 -0700 [thread overview]
Message-ID: <202505011633.82A962A7@keescook> (raw)
In-Reply-To: <a6696d0f-3c5a-46a8-8d38-321292dac83d@arm.com>
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?
> > 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.
--
Kees Cook
next prev parent reply other threads:[~2025-05-01 23:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 22:45 [PATCH] binfmt_elf: Move brk for static PIE even if ASLR disabled Kees Cook
2025-04-28 10:14 ` Ryan Roberts
2025-04-30 19:53 ` Kees Cook
2025-05-01 11:03 ` Ryan Roberts
2025-05-01 23:49 ` Kees Cook [this message]
2025-05-02 10:34 ` Ryan Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202505011633.82A962A7@keescook \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alisaidi@amazon.com \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.