Re: [PATCH] LoongArch: Increase default mmap randomization bits

[Xi Ruoyao]

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.

-- 
Xi Ruoyao <xry111@xxxxxxxxxxx>