From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74077 invoked by alias); 11 Jun 2018 14:50:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 74059 invoked by uid 89); 11 Jun 2018 14:50:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=Hx-languages-length:1383 X-Spam-User: qpsmtpd, 2 recipients X-HELO: brightrain.aerifal.cx Date: Mon, 11 Jun 2018 14:50:00 -0000 From: Rich Felker To: Florian Weimer Cc: GNU C Library , GCC , Binutils Subject: Re: Run (some?) ELF constructors after applying RELRO protection Message-ID: <20180611145013.GG1392@brightrain.aerifal.cx> References: <255b0226-8eb1-93f1-280d-ed004e52ca0e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255b0226-8eb1-93f1-280d-ed004e52ca0e@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2018-06/txt/msg00195.txt.bz2 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