From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.envs.net (mail.envs.net [157.180.15.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B6E9FDDC3 for ; Mon, 13 Apr 2026 02:05:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=157.180.15.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776045941; cv=none; b=BZ1TydudD0B4RzGUL0Ok3MRk1TK6yWGojUP0nWi0UurdhJXURfcWJXnHTsgnnSMHwPgwpph1ngD6zubreji5Wlr7BkRdFy8oOMVrfZdzhs0W2cBaKxUgsZdnQ/39hp7Xu5GVCP1Bs1X5TBw9LnNGXoXm5GaAspgdOsvkADE3Fa8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776045941; c=relaxed/simple; bh=SnbHAobkQmOdD4TXDbAeAcRyxMt6vfBSkx7DgZ5dZYM=; h=Content-Type:MIME-Version:Subject:From:To:Cc:Date:Message-ID: References:In-Reply-To; b=KoOjkNQFI7Z6cqIIVW8Tm/sGLFtOQhR6P5Gmrizfn7lMibkd8tdu7J4Opiwuz6+APbKeTw5ytnuVRP9ff7l2ZyjTSyj1x9Lh0vXavjkrC5vgEYG5dddjF6wZ3Y8ez056VELUBcC+aPy+8V5/1omo8fFCCEm7Q23uVu53WgUoFTw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=envs.net; spf=pass smtp.mailfrom=envs.net; dkim=pass (4096-bit key) header.d=envs.net header.i=@envs.net header.b=cuiqh4iO; arc=none smtp.client-ip=157.180.15.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=envs.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=envs.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=envs.net header.i=@envs.net header.b="cuiqh4iO" Received: from localhost (mail.envs.net [127.0.0.1]) by mail.envs.net (Postfix) with ESMTP id DF8221C00CC; Mon, 13 Apr 2026 02:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=envs.net; s=modoboa; t=1776045934; bh=YvF1kw3b/r0OeHsZoIjDXuEBKtohoXiGA3Lcd4AU+SM=; h=Subject:From:To:Cc:Date:References:In-Reply-To:From; b=cuiqh4iOeXrLY2c6FGfqOXZuEEmevnvR24rLnWXnXZ4LBOz0odsK9CT+rxQG/3KAO NMnAaVtkbezRbZ3dDUS3iu8+O/bRTikDwDFpf3miYTw7ruWckewih6O2vIpEpYI2QB IZ1SqGNQQyNS+tOIdxS+d2JWIIrS7hqLu3HWnfPu8E8/zBnWtdOoX66wm9CRZK1Kii f7gFvfIiqx+ssR3S+OuAvCFXY9gIlwrCsHGSO6N3ScXcWwPUs8ND3DdBQuFMzzc/AN 9SXTQyH4x3ZeoXI9SePsSbr4YAtRbemPpfklC299GPTaN/6m0tYbI92z0WUPm2X6vU quxxhyEq5ZuB1Qygf7RchCNCXDpj/XandXTPWki+bh2IQ7lF/HjeP7fq6+0Yk9IMSH Ci+WrYjaf9dBHTfXIGjN1rHTJO/27qQ5j72cRB+5Ytc/hlprTg8YywwqQsntzhJj/T Jw41OTyuvQHY/CZx0arXgTER9PNED2BeHjfU5nNUgBHcOIBn6UA7Cs99ckEYzDn/xS yK9zpoA6ZlJ5oVYIPq7CK+VAsm5OTddcvNPdXc06r6rUHWOaC1orHaotYF3mBiGPMn Pl6VgKgjGE2y5+z7qurM74wdei5djPtewwqL0cKIfeWCQy8z/xynPncM8nXNhSeoMl VMb5kQBF2lvZPTFOqZ4NsxGg= X-Virus-Scanned: Debian amavisd-new at mail.envs.net Received: from mail.envs.net ([127.0.0.1]) by localhost (mail.envs.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BHP7SLDqFX2l; Mon, 13 Apr 2026 02:05:26 +0000 (UTC) Received: from mail.envs.net (mail.envs.net [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.envs.net (Postfix) with ESMTPSA; Mon, 13 Apr 2026 02:05:26 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH] LoongArch: Increase default mmap randomization bits From: "xtex" To: xry111@xry111.site Cc: chenhuacai@kernel.org, kernel@xen0n.name, guoren@kernel.org, jiaxun.yang@flygoat.com, loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, xtex@astrafall.org Date: Mon, 13 Apr 2026 02:05:26 -0000 Message-ID: <177604592650.1255.8930268562622890190@mail.envs.net> User-Agent: Modoboa 2.2.4 References: In-Reply-To: Xi Ruoyao 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