Run (some?) ELF constructors after applying RELRO protection

[Florian Weimer]

On 06/11/2018 08:59 PM, Rich Felker wrote:
>>> 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).

Perhaps we shoud add a suitable #define to <sys/mman.h>, like 
MAXIMUM_PAGE_SIZE.  Then an application could declare an object this way:

union
{
   struct data data;
   char __minimum_size[MAXIMUM_PAGE_SIZE];
} data __attribute__ ((aligned (MAXIMUM_PAGE_SIZE)));

Hopefully, this will be sufficient to make it safe for applications to 
call mprotect or pkey_mprotect on the actual data.  I always feel bad 
about manipulating memory with mprotect which I have not mapped myself.

Florian