From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 789C81F403 for ; Mon, 11 Jun 2018 14:50:35 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=KGLl IMgZouAMsSucz0u5OItUrYbZRMkDcWWPImQll7frtGm9HHiD5SDX2hjy5LwkB5K3 bcfh0aAql2wiM8hmD9Q/+9Isck5dNiY/n+tQxWuApHWXwvY7UxpFwcK0UwKn6Bd6 1KnxaRNCy2vLOBr59C+hEQVPM2I0U+2qv2bSGSU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=ZpajMXVFKB Q9v0znHygRU3mGkTA=; b=xYNQs9GxF6J00ZzIx+68OE6GO1GX3hdEhaz6Ivk2+F /sEscKqKqop7mEsmftyFaMcruBGfqXqb5hZAQ0sTAwOY4+GBgPMjWILhqITx+mHm g5Th0yoIafGjA5XytAiAwedUEwURmaS1sA43sGBc9/21NUkH4xNz5jZkpxrNDm0H I= 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-Unsubscribe: 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-HELO: brightrain.aerifal.cx Date: Mon, 11 Jun 2018 10:50:13 -0400 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) 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