[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D52A947C-0AEC-4310-B2C5-519BBE46037C@dwheeler.com>
Date: Mon, 8 Jul 2024 16:14:40 -0400
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: oss-security@...ts.openwall.com
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 <fweimer@...hat.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
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.
