Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch

["David A. Wheeler" <dwheeler () dwheeler com>]

> * 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 <fweimer () redhat com> 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 libc.so.6.  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 libc.so.6.

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

> The kernel should not apply hugepage optimizations to mappings created
> with MAP_DENYWRITE.

Shouldn't that be MAP_EXECUTABLE, not MAP_DENYWRITE?
If you use 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:
https://man7.org/linux/man-pages/man2/mmap.2.html
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