[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260618223827.GP27423@brightrain.aerifal.cx>
Date: Thu, 18 Jun 2026 18:38:27 -0400
From: Rich Felker <dalias@...c.org>
To: Fangrui Song <i@...kray.me>
Cc: musl@...ts.openwall.com
Subject: Re: Feature request: Support multiple PT_GNU_RELRO in ldso
On Fri, Jun 12, 2026 at 07:28:49PM -0700, Fangrui Song wrote:
> Multi-GOT executables are being explored for two main use cases: (1)
> managing huge binaries, and (2) CHERI compartmentalization. Because
> each GOT needs to be write-protected after relocation, the dynamic
> linker needs to support multiple PT_GNU_RELRO segments.
> https://discourse.llvm.org/t/rfc-forming-a-massive-binaries-working-group-in-lld/91031/5
I think this change can be made, and it's likely cleaner than what we
have now. Doing it involves removing the relro_start and relro_end
members from struct dso and instead iterating over the phdrs later
when applying the relro mprotect so we can apply as many as there are.
> If musl implements multi-RELRO support, reclaim_gaps can be adjusted
> to conservatively check the first RELRO range.
I think you're mistaken on that. reclaim() needs to exclude any memory
that will be made read-only or the use of that memory will fault
later. Just checking the first range is not "conservative" but
outright insufficient.
Applying multiple relros in a fully general manner here would involve
operations that would potentially split ranges and incur a lot of
complexity. But we're in luck, because the ranges passed on reclaim()
are always partial pages to begin with.
The logic there now to cut off parts covered by relro is extraneous;
all we actually care about is whether the page is subject to relro, in
which case the whole reclaim() needs to be skipped.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
