This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Run (some?) ELF constructors after applying RELRO protection
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, GCC <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 11 Jun 2018 10:50:13 -0400
- Subject: Re: Run (some?) ELF constructors after applying RELRO protection
- References: <255b0226-8eb1-93f1-280d-ed004e52ca0e@redhat.com>
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