From: Bingwu Zhang <xtex@envs.net>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>, Guo Ren <guoren@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
Bingwu Zhang <xtex@astrafall.org>
Subject: Re: [PATCH] LoongArch: Increase default mmap randomization bits
Date: Sun, 12 Apr 2026 11:49:10 +0800 [thread overview]
Message-ID: <4731624.LvFx2qVVIh@xtex1> (raw)
In-Reply-To: <CAAhV-H5Y=iPfS5FLN92eL+KauSfuLsPtiSajfFnjaQqXOtuYdA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]
On Sunday, March 29, 2026 11:48:02 AM China Standard Time Huacai Chen wrote:
> Hi, Bingwu,
>
> On Sun, Mar 29, 2026 at 6:59 AM Bingwu Zhang <xtex@envs.net> wrote:
> > From: Bingwu Zhang <xtex@astrafall.org>
> >
> > Increase default mmap randomization bits from 12 to 18 on 64-bit
> > platforms for better strength.
> >
> > The original default, 12, means that ASLR offset has only (1 << 12) =
> > 4096 possibilities. On average, it can be brute-forced in 2048 attempts.
> > If a service is configured to restart automatically or can be started
> > easily (e.g. execve a suid program), then trying for 4k times can be
> > done in one day even when each attempt takes 20s.
> > Increasing it to 18 makes brute-force much more difficult and leaves
> > more time for operators to find out attacks.
> >
> > On 64-bit platforms, virtual address space is cheap, so the
> > randomization bits can be increased safely without disturbing userland
> > much and security comes first instead of availability.
>
> Don't change ARCH_MMAP_RND_BITS_MIN because it may compact
> performance, and you cannot blindly increase ARCH_MMAP_RND_BITS_MAX
> because it should no more than "VA_BITS - PAGE_SHIFT - 3" (see
> arch/riscv/Kconfig and arch/csky/Kconfig). For LoongArch, VA_BITS can
> be 39 (half of VA40), PAGE_SHIFT can be 16 (64KB page), so
> ARCH_MMAP_RND_BITS_MAX can only increase up to 20 (39 - 16 - 3 =20).
Sorry for the late reply.
It was my mistake that I didn't notice the upper bound of MAX. Thank you for
pointing out!
However, I didn't get where increasing MIN could compact performance.
Theoretically, the only difference is that the gap between heaps and stacks
are larger, from [128, 128+64]M to [128, 128+4096]M. This shouldn't affect
performance much. MIPS once used MIN=16, RISC-V 64 and PowerPC and ARM 64 are
using 18, and x86-64 is using 28, but I hadn't heard anyone complaining about
the performance.
I ran some benchmarks last weekend using the LLVM build benchmark of AOSC OS
https://github.com/AOSC-Dev/buildbot-benchmark/blob/master/buildbot-benchmark.bash
and here are the results
Processor Rand bits Time/secs
Average Variance Range
3C6000/S 18 612.927 614.394 614.513 613.343 614.76
613.9874 0.515637840000006 1.83299999999997
3C6000/S 12 614.322 613.93 614.825 613.859
615.875 614.5622 0.548874160000007 2.01599999999996
3A5000 18 3547.165 3548.764 3552.192 3545.697
3547.567 3548.277 4.79228759999993 6.49499999999989
3A5000 12 3549.029 3551.894 3549.191 3567.869
3587.409 3561.0784 222.052853440003 38.3800000000001
I didn't see any statistically meaningful performance defect.
>
> These are done in:
> https://github.com/chenhuacai/linux/commit/ff35475dcfbd4c6e9c275aaef3c92da71
> 0894058
>
> Huacai
>
> > Fixes: fa96b57c1490 ("LoongArch: Add build infrastructure")
> > Signed-off-by: Bingwu Zhang <xtex@astrafall.org>
> > ---
> >
> > arch/loongarch/Kconfig | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> > index 92068ff38685..b47c4e4ecbb7 100644
> > --- a/arch/loongarch/Kconfig
> > +++ b/arch/loongarch/Kconfig
> > @@ -740,9 +740,11 @@ config MMU
> >
> > default y
> >
> > config ARCH_MMAP_RND_BITS_MIN
> >
> > + default 18 if 64BIT
> >
> > default 12
> >
> > config ARCH_MMAP_RND_BITS_MAX
> >
> > + default 32 if 64BIT
> >
> > default 18
> >
> > config ARCH_SUPPORTS_UPROBES
> >
> > base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> > --
> > 2.52.0
Best regards,
--
Bingwu Zhang @ Sun, 12 Apr 2026 03:28:14 +0000
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
next prev parent reply other threads:[~2026-04-12 3:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-28 22:59 [PATCH] LoongArch: Increase default mmap randomization bits Bingwu Zhang
2026-03-29 3:48 ` Huacai Chen
2026-04-12 3:49 ` Bingwu Zhang [this message]
2026-04-12 12:24 ` Huacai Chen
2026-04-12 12:32 ` Xi Ruoyao
2026-04-12 12:36 ` Huacai Chen
2026-04-12 12:37 ` Xi Ruoyao
2026-04-12 12:42 ` Huacai Chen
2026-04-13 2:05 ` xtex
2026-04-13 2:05 ` xtex
2026-04-13 2:38 ` Huacai Chen
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=4731624.LvFx2qVVIh@xtex1 \
--to=xtex@envs.net \
--cc=chenhuacai@kernel.org \
--cc=guoren@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=xtex@astrafall.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).