Re: [PATCH] LoongArch: Increase default mmap randomization bits
From: Huacai Chen
Date: Sun Apr 12 2026 - 22:38:43 EST
On Mon, Apr 13, 2026 at 10:05 AM xtex <xtex@xxxxxxxx> wrote:
>
> Xi Ruoyao <xry111@xxxxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx>
> >> > > > wrote:
> >> > > > > From: Bingwu Zhang <xtex@xxxxxxxxxxxxx>
> >> > > > >
> >> > > > > 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.
Maybe it should be 0, but keeping the old value is better because I
think there are some historic reasons.
Huacai
>
> >
> >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@xxxxxxxxxxx>
>
> Bingwu Zhang
>