[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260908012151.GG23438@brightrain.aerifal.cx>
Date: Mon, 7 Sep 2026 21:21:52 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: Add relro protections for static linking
On Mon, Mar 30, 2026 at 07:24:03PM +0200, Markus Wichmann wrote:
> Hi all,
>
> As explained in the commit message, in static PIE, relro is sensible.
> But until now nothing was applying the protection. Relocations were
> handled in rcrt1.o, and then the normal static initialization proceeded.
> The only function that looks at the program headers in that case is
> static_init_tls(), so I am adding this there. Is the attached patch
> acceptable?
I'm not sure. This feels like a hack, just because it's code that
deals with phdrs already. It's not specific to static pie, and would
also be executing in non-pie static executables.
My leaning would be to have __dls2 in rcrt1.c do it. This is analogous
to where the dynamic linker would do it and only linked for
static-pie.
> On another note, while looking at that function: Is it maybe sensible to
> add malloc memory donation to it as well? Or is the LOAD segment
> overhang different in static linking somehow?
I seem to recall a long time ago not doing the donation with static
linking for some reason, but I don't remember the details. It might
have been that old kernels had the brk start mid-page at the end of
bss, and that we were using raw brk without page alignment for the
bump allocator. Or it might have been a matter of complex weak
reference logic to avoid pulling in malloc unnecessarily.
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.
