Run (some?) ELF constructors after applying RELRO protection

Run (some?) ELF constructors after applying RELRO protection

[Florian Weimer]

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?

Thanks,
Florian

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

[Rich Felker]

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

Rich

Re: 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

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

[Rich Felker]

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

Re: 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