* [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®