[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aqAY4Ty0f08JpOrk@intrepid>
Date: Tue, 8 Sep 2026 16:17:05 +0200
From: Markus Wichmann <nullplan@....net>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Add relro protections for static linking
Am Mon, Sep 07, 2026 at 09:21:52PM -0400 schrieb Rich Felker:
> 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.
>
True, the code runs. But I don't know how to make a linker generate a
relro segment in non-PIE executables. That wouldn't make a lot of sense.
So it would run but not find anything, and thus not do anything. Only
difference would be that the code grows by a few bytes.
And yes, it is a hack, but only because static_init_tls() is already a
hack that does more than initialize TLS. The function has already
acquired one more use case with the handling of PT_GNU_STACK segments.
But that only indicates that the name went out-of-date, and maybe the
function should be called "init_from_phdrs" or something like that.
> 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.
>
That is also a solution, but it adds the stack and auxv decoding stuff
to rcrt1.c, duplicating it from __init_libc().
> > 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
Looking at it more, it seems that calling __malloc_donate() will always
pull in the big malloc, and thus preclude the bump allocator from
working. Which we could fix up with weak references (a donation function
that only does something when the big malloc is also linked in), but
yeah, it seems like that would be digging pretty deep for a pretty small
potatoe. Particularly since mallocng has its donation function in a
separate file, probably for good reason as well.
Ciao,
Markus
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.
