* Run (some?) ELF constructors after applying RELRO protection @ 2018-02-27 12:05 Florian Weimer 2018-06-11 14:50 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2018-02-27 12:05 UTC (permalink / raw) To: GNU C Library, GCC, Binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Run (some?) ELF constructors after applying RELRO protection 2018-02-27 12:05 Run (some?) ELF constructors after applying RELRO protection Florian Weimer @ 2018-06-11 14:50 ` Rich Felker 2018-06-11 17:50 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2018-06-11 14:50 UTC (permalink / raw) To: Florian Weimer; +Cc: GNU C Library, GCC, Binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Run (some?) ELF constructors after applying RELRO protection 2018-06-11 14:50 ` Rich Felker @ 2018-06-11 17:50 ` Florian Weimer 2018-06-11 18:59 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2018-06-11 17:50 UTC (permalink / raw) To: Rich Felker; +Cc: GNU C Library, GCC, Binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Run (some?) ELF constructors after applying RELRO protection 2018-06-11 17:50 ` Florian Weimer @ 2018-06-11 18:59 ` Rich Felker 2018-07-05 19:49 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2018-06-11 18:59 UTC (permalink / raw) To: Florian Weimer; +Cc: GNU C Library, GCC, Binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Run (some?) ELF constructors after applying RELRO protection 2018-06-11 18:59 ` Rich Felker @ 2018-07-05 19:49 ` Florian Weimer 0 siblings, 0 replies; 5+ messages in thread From: Florian Weimer @ 2018-07-05 19:49 UTC (permalink / raw) To: Rich Felker; +Cc: GNU C Library, GCC, Binutils 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-05 19:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-27 12:05 Run (some?) ELF constructors after applying RELRO protection Florian Weimer 2018-06-11 14:50 ` Rich Felker 2018-06-11 17:50 ` Florian Weimer 2018-06-11 18:59 ` Rich Felker 2018-07-05 19:49 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).