From: Florian Weimer <fweimer@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: mail@horotw.com, linux-hardening@vger.kernel.org,
Jakub Wilk <jwilk@jwilk.net>,
Salvatore Bonaccorso <carnil@debian.org>,
Linux Memory Management List <linux-mm@kvack.org>,
William Kucharski <william.kucharski@oracle.com>
Subject: Re: Limited/Broken functionality of ASLR for Libs >= 2MB
Date: Mon, 22 Jan 2024 10:48:17 +0100 [thread overview]
Message-ID: <87ede9pula.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <ZaWZqnD7XmP5HMA0@casper.infradead.org> (Matthew Wilcox's message of "Mon, 15 Jan 2024 20:46:34 +0000")
* Matthew Wilcox:
> I received a suggestion off-list that we only do the PMD alignment on
> 64-bit, which seems quite reasonable to me. After all, I don't care
> about performance on 32-bit just as much as I don't care about security
> on 32-bit.
Perhaps we can we repurpose MAP_DENYWRITE to disable this?
For shared objects as loaded by a dynamic linker, the alignment is
pointless in many cases even if the original mapping is quite a bit
larger than 2 MiB because the individual LOAD segments and their
protection settings are smaller than 2 MiB, so hugepages cannot be used
in the end after all. The dynamic linker knows the LOAD segments, so it
can drop MAP_DENYWRITE if it determines that hugepages could be
beneficial. (Current glibc sets MAP_DENYWRITE for historic reasons.)
On the other hand, I wouldn't object to more explicit control over mmap
pointer alignment, either, for anonymous mappings as well.
There are some binutils versions that produce 2 MiB aligned file layout
on x86-64, but that change was reverted, presumably because kernel
hugepage support for non-anonymous memory wasn't available. But there
are likely some iffy details that make these binaries unusable for
hugepages in practice, like lack of hugepage alignment at the end of
LOAD segments. Unfortunately, BFD ld tends to produce approximate
PT_LOAD and PT_GNU_RELRO and relies on the dynamic loader to round
things up and down in somewhat questionable ways.
Thanks,
Florian
prev parent reply other threads:[~2024-01-22 9:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <69fa6015256613ed10aee996e181ebd4@horotw.com>
2024-01-15 16:40 ` Sam James
2024-01-15 16:52 ` Matthew Wilcox
2024-01-15 18:21 ` mail
2024-01-15 20:46 ` Matthew Wilcox
2024-01-16 8:09 ` Ard Biesheuvel
2024-01-23 22:35 ` Kees Cook
2024-01-24 1:04 ` Yang Shi
2024-01-24 16:08 ` Kees Cook
2024-01-22 9:48 ` Florian Weimer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ede9pula.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=carnil@debian.org \
--cc=jwilk@jwilk.net \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mail@horotw.com \
--cc=william.kucharski@oracle.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox