From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37235 invoked by alias); 11 Jun 2018 18:32:27 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 37224 invoked by uid 89); 11 Jun 2018 18:32:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=recommendations, harden, pay, wish X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qt0-f179.google.com Received: from mail-qt0-f179.google.com (HELO mail-qt0-f179.google.com) (209.85.216.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Jun 2018 18:32:25 +0000 Received: by mail-qt0-f179.google.com with SMTP id x34-v6so21238071qtk.5 for ; Mon, 11 Jun 2018 11:32:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WHPug7QwfxXlZSl4fpefL22WhCt9iFNkX3bXySzijCM=; b=Jcu9tPkVOYJwP0Yc+d3SFH4Cr2POFt8kDA96kYAyDwWgUFSHTAaCMRoJ3Sckw8dpFm tQ+JQr09s5GUriMbVCUmMDB86t8tnyWvoGn9j1tnqQ3F/2AAlUyXbiiV0LulaWh1L8bf hVE4uan1Tq2iIt3RPZZkzCNLC3OZxV7Mc+fBZtOpe/Ml/BZdtH6r9THiQYK9c3ac3Dwv d0NlIr4FOHuHwCQTmV2ptmLRjYnlM4K3ymuce9NQ1+3YhD7wBs0/aarkQDk0lduEiSYm PwbOoaA9gMckPPW2+f2M9yoFuuNjDbEw/QMFKUNa9O02enABfEq5xutj8veD/Y++vIzR Sysw== X-Gm-Message-State: APt69E0omIYbaU5fHnIx1KOkKGdGVpG+Qt+8fa5NXvDH1buhnKMhEY/4 k8J0NnuhO0TMQAwp9iC7bYKyE+h+iuI= X-Google-Smtp-Source: ADUXVKI7yeDogWhUPOW+/tI2ZCPIlYEJehjr4rexy4MDmdPvoJf/6e25kZJj7T3ZclfU0f02+SMVig== X-Received: by 2002:ac8:37a5:: with SMTP id d34-v6mr354859qtc.76.1528741942753; Mon, 11 Jun 2018 11:32:22 -0700 (PDT) Received: from [192.168.8.100] ([184.151.36.206]) by smtp.gmail.com with ESMTPSA id y188-v6sm20769481qkb.23.2018.06.11.11.32.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 11:32:21 -0700 (PDT) Subject: Re: Flag for late RELRO application To: Florian Weimer , gnu-gabi@sourceware.org References: <0140c64d-ceef-070e-a8f5-95a930984800@redhat.com> <7a4054dc-561c-544f-b3d5-4f06580e10dc@redhat.com> <1e8cc2f8-1726-7fed-f905-05610417c8af@redhat.com> From: Carlos O'Donell Message-ID: <0e56bdc1-95a1-8626-cba1-2f0ef937f5ab@redhat.com> Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1e8cc2f8-1726-7fed-f905-05610417c8af@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00003.txt.bz2 On 06/11/2018 01:37 PM, Florian Weimer wrote: > On 06/11/2018 06:29 PM, Carlos O'Donell wrote: >> If you have to markup existing code with >> attributes to get this to work, you might as well collect them >> into a special section and use a 'late RELRO' flag for it, >> extending the existing RELRO framework. > > Again, is this really worth the complexity? Consider the behaviour the flag will enable. Say it becomes wildly successful, and all application authors turn it on. Now, everyone is using "LATE" (flag) + "RELRO." Maybe even against your recommendations. If we wish to further harden such binaries (applying some of RELRO earlier again), would we have a way to do so easily? Do we have to define the "late RELRO" flag in such a way as to guide implementations to make choices that allow them to continue to be able to incrementally harden applications? For example: DT_FLAGS: * DF_LATE_RELRO flag set in DT_FLAGS if the dynamic loader should run all constructors and initializers before marking all relocations read-only. Special Sections: * ".data.re.ro.late" - SHT_PROGBITS, SHF_ALLOC+SHF_WRITE This section holds data that must be writable until after all constructors and initializers have been run. Implementation considerations: * The guidance to linker implementations is that DF_LATE_RELRO should only be set if an input section contained data in the section ".data.rel.ro.late" to disambiguate the data that really needs the late RELRO semantics from those that don't. So we can eventually harden in two stages. For now the linker can choose to merge everything together and let the dynamic loader delay RELRO. In this way we define the flag, *and* a section for late RELRO in such a way that we can find these uses later if we want to move them or further harden such binaries. This is a bit more work, but I think it will pay dividends if we ever need to do further hardening. Thoughts? Cheers, Carlos.