Re: Run (some?) ELF constructors after applying RELRO protection

[Rich Felker <dalias@libc.org>]

On Mon, Jun 11, 2018 at 07:50:32PM +0200, Florian Weimer wrote:
> On 06/11/2018 04:50 PM, Rich Felker wrote:
> >On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> >>I think it would be a nice addition to the toolchain if it were
> >>possible to programatically initialize data in the RELRO section.
> >>We do this in glibc, but I don't think this is currently supported
> >>for general use.
> >>
> >>One important application is to allocate a memory region with mmap,
> >>on which protection flags can be changed as needed.  This way, the
> >>application can have a read-only path to its own configuration data,
> >>for example.
> >>
> >>Do you think this would be worthwhile to implement?  Any suggestions
> >>how we should do it, without needing binutils/GCC/glibc updates?
> >
> >This weakens protection of the actual relro section (because there's a
> >window where it's writable but application code is running; in the
> >case of thread creation from ctors, or dlopen in a multithreaded
> >program, this is a nontrivial window) and has no benefit, except
> >saving a page of memory, over the application just calling mprotect
> >itself.
> 
> My latest proposal suggests to make this opt-in:
> 
>   <https://sourceware.org/ml/gnu-gabi/2018-q2/msg00000.html>

Yes, I saw this first but went back to the old post on libc-alpha to
reply because I don't have a Message-ID to reply to the new one (I'm
not subscribed to gnu-gabi; I probably should be though).

> >If the application already has to annotate that the data is
> >going to be read-only after ctors, it can just page-align/page-pad the
> >data itself and call mprotect with minimal additional effort, and no
> >complex interaction between application code and relro (which is about
> >RELocations not arbitrary data protection).
> 
> Is this really supported?  We currently do not provide programmatic
> access to the largest supported page size of a target architecture,
> I think.  The link editor knows of it, of course, but beyond that,
> it's a bit of a mystery.  It's not just about cross-compilation.
> Even if you check the run-time page size, it might not give you the
> right answer.

Hmm, that's a good point. In that case something new is needed. If you
really want to do it with the dynamic linker, I think it should be a
new program header though rather than a flag, and a new section/pages
separate from RELRO (since it's more like POSTCTORRO). With a flag, if
the dynamic linker is old and lacks support for it, the program will
crash when the ctor runs and can't write because the RELRO mprotect
was already applied. Making it separate would also protect the
existing RELRO ASAP so that it's not exposed during ctor execution.

Rich