From: Kees Cook <kees@kernel.org>
To: David Gow <davidgow@google.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>,
Luis Chamberlain <mcgrof@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Walleij <linus.walleij@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: Only enforce minimum stack gap size if it's sensible
Date: Mon, 5 Aug 2024 10:26:36 -0700 [thread overview]
Message-ID: <202408051025.33CA44DEE6@keescook> (raw)
In-Reply-To: <20240803074642.1849623-2-davidgow@google.com>
On Sat, Aug 03, 2024 at 03:46:41PM +0800, David Gow wrote:
> The generic mmap_base code tries to leave a gap between the top
> of the stack and the mmap base address, but enforces a minimum
> gap size (MIN_GAP) of 128MB, which is too large on some setups. In
> particular, on arm tasks without ADDR_LIMIT_32BIT, the STACK_TOP
> value is less than 128MB, so it's impossible to fit such a gap in.
>
> Only enforce this minimum if MIN_GAP < MAX_GAP, as we'd prefer to honour
> MAX_GAP, which is defined proportionally, so scales better and always
> leaves us with both _some_ stack space and some room for mmap.
>
> This fixes the usercopy KUnit test suite on 32-bit arm, as it doesn't
> set any personality flags so gets the default (in this case 26-bit)
> task size. This test can be run with:
> ./tools/testing/kunit/kunit.py run --arch arm usercopy --make_options LLVM=1
>
> Fixes: dba79c3df4a2 ("arm: use generic mmap top-down layout and brk randomization")
> Signed-off-by: David Gow <davidgow@google.com>
> ---
>
> This is one possible fix for an issue with the usercopy_kunit suite
> (and, indeed, the KUnit user_alloc features) on 32-bit arm. The other
> options are to:
> - hack the KUnit allocation to force ADDR_LIMIT_32BIT or
> ADDR_COMPAT_LAYOUT; or
> - similarly, use an unlimited stack, which forces the legacy layout
> behind the scenes; or
> - adjust MIN_GAP based on either STACK_TOP or architecture.
>
> Of them, I made the arbitrary call that this was least hacky, but am
> happy to go with something else if someone who actually knows what's
> going on suggests it.
>
> (Also, does this issue actually mean some strange legacy binaries have
> been broken with an rlimit-ed stack for ages? Or am I missing something?)
>
> Cheers,
> -- David
I see akpm already snagged this, but yeah, this looks like a totally
sane fix. Thanks for digging in and finding the problem!
Reviewed-by: Kees Cook <kees@kernel.org>
-Kees
>
> ---
> mm/util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/util.c b/mm/util.c
> index bd283e2132e0..baca6cafc9f1 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -463,7 +463,7 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
> if (gap + pad > gap)
> gap += pad;
>
> - if (gap < MIN_GAP)
> + if (gap < MIN_GAP && MIN_GAP < MAX_GAP)
> gap = MIN_GAP;
> else if (gap > MAX_GAP)
> gap = MAX_GAP;
> --
> 2.46.0.rc2.264.g509ed76dc8-goog
>
--
Kees Cook
prev parent reply other threads:[~2024-08-05 17:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-03 7:46 David Gow
2024-08-05 17:26 ` Kees Cook [this message]
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=202408051025.33CA44DEE6@keescook \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=davidgow@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mcgrof@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox