From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71138 invoked by alias); 20 Mar 2019 14:51:28 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 71126 invoked by uid 89); 20 Mar 2019 14:51:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=matz, Matz X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Mar 2019 14:51:26 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2008E300042C; Wed, 20 Mar 2019 15:51:22 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id C5484413CC0F; Wed, 20 Mar 2019 15:51:22 +0100 (CET) Message-ID: Subject: Re: GNU property saga From: Mark Wielaard To: Michael Matz , x86-64-abi@googlegroups.com Cc: binutils@sourceware.org Date: Wed, 20 Mar 2019 14:51:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2019-03/txt/msg00127.txt.bz2 Hi, On Mon, 2019-03-04 at 17:25 +0000, Michael Matz wrote: > I'll admit that I have lost track of the consensus about GNU > properties and all the discussions last year. But we want to > somewhen get this into the psABI document. Thanks for picking this up. These things have a way of creeping up in the various code bases without ever really reaching consensus. Causing sad faces everywhere. Lets see if we can agree on something. As far as I understand we did reach (a somewhat forced) consensus on how to represent the IBT and Shadow Stack and Stack Size support which the current glibc dynamic loader depends on. The consensus on representation of those properties is described here: https://sourceware.org/ml/binutils/2018-09/msg00282.html But there doesn't seem to be any consensus anyon other/new GNU property features or notes that would require the new (and/or) semantics. bintuils and glibc don't even agree on the names and values of these new feature properties. You already split the discussion of the and/or semantics of those new property features off into another thread. I think the answer to the questions you pose below should also be split for the existing GNU Properties (IBT/SHST/STACK_SIZE) and the new property/note features. > I believe there were two points (with subitems) of contentions: > > 1) use PT_NOTE vs PT_xxx for program header containing the properties >=20 > I believe the consensus was to use a new PT_xxx value As far as I understand the current consensus, for the existing property features, it is actually the opposite. There will be a new PT_NOTE segment with (for ELFCLASS64) larger alignment and padding. This is what the current glibc dynamic loader depends on. But for the new GNU Property features it does seem that people would prefer to use a new PT_xxx value. There is a new constant in binutils: #define PT_GNU_PROPERTY (PT_LOOS + 0x474e553) /* GNU property */ But that isn't used anywhere else. Question is, if we are going to use that for new GNU Property features, should we also do that for the old ones and how does that impact the existing binaries/dynamic libraries? > 1a) use new SHT_xxx for sections contain such properties >=20 > I believe the consensus was to stay with SHT_NOTE, even though that > is squarely against ELF spirit. Yes, for the existing GNU Properties. But I think it would be a bad idea for the new property features if those will use a new PT value segment type. Then the rules for composing SHT_NOTEs become even more complex. You already need to distinguish between existing (GNU) notes which don't combine with the new (Property) notes because they use different alignment and padding rules. Then you would also get even different notes that don't combine with any of the existing ones. At least, the rules for combining them are not clear to me. Cheers, Mark