From: "xtex" <xtex@envs.net>
To: xry111@xry111.site
Cc: chenhuacai@kernel.org, kernel@xen0n.name, guoren@kernel.org,
jiaxun.yang@flygoat.com, loongarch@lists.linux.dev,
linux-kernel@vger.kernel.org, xtex@astrafall.org
Subject: Re: [PATCH] LoongArch: Increase default mmap randomization bits
Date: Mon, 13 Apr 2026 02:05:26 -0000 [thread overview]
Message-ID: <177604592650.1255.8930268562622890190@mail.envs.net> (raw)
In-Reply-To: <b04efb5af4f5019adbb0adb8543bd84b8157e8e1.camel@xry111.site>
Xi Ruoyao <xry111@xry111.site> wrote:
>On Sun, 2026-04-12 at 20:32 +0800, Xi Ruoyao wrote:
>> On Sun, 2026-04-12 at 20:24 +0800, Huacai Chen wrote:
>> > On Sun, Apr 12, 2026 at 11:49 AM Bingwu Zhang <xtex@envs.net> wrote:
>> > >
>> > > 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.
>> > OK, then we can increase ARCH_MMAP_RND_BITS_MIN, but the range 18~20
>> > seems too small and then useless, can we consider using 15~20?
>>
>> IMO ARCH_MMAP_RND_BITS_MIN should be just the minimal that the
>> architecture can support, not related to security. If you want to
>> recommend a value for increasing security you'd set
>> ARCH_MMAP_RND_BITS_DEFAULT a larger value instead.
okay, I agree to abandon this patch. But,
Isn't the minimum supported value 0 (i.e. mmap ASLR disabled)? There is always a fixed 128M gap between heaps and stack tops so 0 should work.
>
>I.e. for example if someone is building a distro running on an embedded
>system where avoiding addr space fragmentation is more important than
>security we shouldn't be stopping him to decrease ARCH_MMAP_RND_BITS
>unless he reaches the architecture minimum. Instead we should increase
>ARCH_MMAP_RND_BITS_DEFAULT so the "typical" systems get a larger
>ARCH_MMAP_RND_BITS.
Is address space fragmentation that important on embedded systems? Isn't it obvious that you will never have 300G RAM on embedded systems?
>
>--
>Xi Ruoyao <xry111@xry111.site>
Bingwu Zhang
next prev parent reply other threads:[~2026-04-13 2:05 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
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 [this message]
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=177604592650.1255.8930268562622890190@mail.envs.net \
--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=xry111@xry111.site \
--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).