* [PATCH] LoongArch: Increase default mmap randomization bits
@ 2026-03-28 22:59 Bingwu Zhang
2026-03-29 3:48 ` Huacai Chen
0 siblings, 1 reply; 11+ messages in thread
From: Bingwu Zhang @ 2026-03-28 22:59 UTC (permalink / raw)
To: Huacai Chen, WANG Xuerui, Guo Ren, Jiaxun Yang
Cc: loongarch, linux-kernel, Bingwu Zhang
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.
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
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
0 siblings, 1 reply; 11+ messages in thread
From: Huacai Chen @ 2026-03-29 3:48 UTC (permalink / raw)
To: Bingwu Zhang
Cc: WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch, linux-kernel, Bingwu Zhang
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).
These are done in:
https://github.com/chenhuacai/linux/commit/ff35475dcfbd4c6e9c275aaef3c92da710894058
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
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
2026-03-29 3:48 ` Huacai Chen
@ 2026-04-12 3:49 ` Bingwu Zhang
2026-04-12 12:24 ` Huacai Chen
0 siblings, 1 reply; 11+ messages in thread
From: Bingwu Zhang @ 2026-04-12 3:49 UTC (permalink / raw)
To: Huacai Chen
Cc: WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch, linux-kernel, Bingwu Zhang
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
2026-04-12 3:49 ` Bingwu Zhang
@ 2026-04-12 12:24 ` Huacai Chen
2026-04-12 12:32 ` Xi Ruoyao
0 siblings, 1 reply; 11+ messages in thread
From: Huacai Chen @ 2026-04-12 12:24 UTC (permalink / raw)
To: Bingwu Zhang
Cc: WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch, linux-kernel, Bingwu Zhang
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?
Huacai
>
> >
> > 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
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
0 siblings, 2 replies; 11+ messages in thread
From: Xi Ruoyao @ 2026-04-12 12:32 UTC (permalink / raw)
To: Huacai Chen, Bingwu Zhang
Cc: WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch, linux-kernel, Bingwu Zhang
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.
--
Xi Ruoyao <xry111@xry111.site>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
2026-04-12 12:32 ` Xi Ruoyao
@ 2026-04-12 12:36 ` Huacai Chen
2026-04-12 12:37 ` Xi Ruoyao
1 sibling, 0 replies; 11+ messages in thread
From: Huacai Chen @ 2026-04-12 12:36 UTC (permalink / raw)
To: Xi Ruoyao
Cc: Bingwu Zhang, WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch,
linux-kernel, Bingwu Zhang
On Sun, Apr 12, 2026 at 8:32 PM Xi Ruoyao <xry111@xry111.site> 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.
If so, just keep 12.
Huacai
>
> --
> Xi Ruoyao <xry111@xry111.site>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
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
` (2 more replies)
1 sibling, 3 replies; 11+ messages in thread
From: Xi Ruoyao @ 2026-04-12 12:37 UTC (permalink / raw)
To: Huacai Chen, Bingwu Zhang
Cc: WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch, linux-kernel, Bingwu Zhang
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.
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.
--
Xi Ruoyao <xry111@xry111.site>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
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
2 siblings, 0 replies; 11+ messages in thread
From: Huacai Chen @ 2026-04-12 12:42 UTC (permalink / raw)
To: Xi Ruoyao
Cc: Bingwu Zhang, WANG Xuerui, Guo Ren, Jiaxun Yang, loongarch,
linux-kernel, Bingwu Zhang
On Sun, Apr 12, 2026 at 8:37 PM 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.
>
> 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.
Hmm, ARCH_MMAP_RND_BITS is visible and configurable, so just keep
ARCH_MMAP_RND_BITS_MIN as 12.
Huacai
>
> --
> Xi Ruoyao <xry111@xry111.site>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
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
2 siblings, 0 replies; 11+ messages in thread
From: xtex @ 2026-04-13 2:05 UTC (permalink / raw)
To: xry111
Cc: chenhuacai, kernel, guoren, jiaxun.yang, loongarch, linux-kernel, xtex
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
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
2 siblings, 1 reply; 11+ messages in thread
From: xtex @ 2026-04-13 2:05 UTC (permalink / raw)
To: xry111
Cc: chenhuacai, kernel, guoren, jiaxun.yang, loongarch, linux-kernel, xtex
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] LoongArch: Increase default mmap randomization bits
2026-04-13 2:05 ` xtex
@ 2026-04-13 2:38 ` Huacai Chen
0 siblings, 0 replies; 11+ messages in thread
From: Huacai Chen @ 2026-04-13 2:38 UTC (permalink / raw)
To: xtex; +Cc: xry111, kernel, guoren, jiaxun.yang, loongarch, linux-kernel, xtex
On Mon, Apr 13, 2026 at 10:05 AM xtex <xtex@envs.net> wrote:
>
> 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.
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@xry111.site>
>
> Bingwu Zhang
>
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2026-04-13 2:38 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2026-04-13 2:05 ` xtex
2026-04-13 2:38 ` Huacai Chen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®