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

[Florian Weimer <fweimer at redhat dot com>]

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>

> 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.

Thanks,
Florian