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

[Florian Weimer <fweimer at redhat dot com>]

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