Run (some?) ELF constructors after applying RELRO protection

[Florian Weimer]

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