Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Jul 2024 16:14:40 -0400
From: "David A. Wheeler" <>
Subject: Re: ASLRn't is still alive and well on x86 kernels,
 despite CVE-2024-26621 patch

> * Will Dormann:
> - Modern (e.g. 6.x kernel) x86 platforms load a large-enough libc at
>>   the same address every time. (i.e. no practical ASLR -- "ASLRn't")

For clarity, I'm going use the term "x86_32" to clarify that we're talking about
32-bit architectures & *excluding* the far-more-common 64-bit case.

> On Jul 8, 2024, at 1:28 PM, Florian Weimer <> wrote:
> Please note that current glibc is not large enough to benefit from 2 MiB
> hugepages because all load segments are smaller than 2 MiB, so it's just
> not possible to use hugepages for  This is with the default
> -z separate-code in current binutils.  Even with -z noseparate-code, the
> large readable-executable load segment is still a bit less than 2 MiB.
> Unfortunately the kernel does not know this when we reserve the address
> space for the entirety of

So clearly there needs to be a way to provide this information :-).

> The kernel should not apply hugepage optimizations to mappings created

Shouldn't that be MAP_EXECUTABLE, not MAP_DENYWRITE?
a program that mmaps in a large non-code dataset won't have hugepage
optimizations applied, which might be a significant performance regression.

Also, the mmap man page:
says that  MAP_EXECUTABLE and MAP_DENYWRITE are ignored.
There's a risk that some programs are taking that to heart & not using those flags
even when they should. If one of those flags *will* have an effect now, then it'd be a good idea
to document that :-).

--- David A. Wheeler

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.