From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34220 invoked by alias); 22 Feb 2020 05:19:27 -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 34194 invoked by uid 89); 22 Feb 2020 05:19:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=stakeholders, H*F:D*me, strangely, Hope X-HELO: mail-pj1-f67.google.com Received: from mail-pj1-f67.google.com (HELO mail-pj1-f67.google.com) (209.85.216.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 22 Feb 2020 05:19:16 +0000 Received: by mail-pj1-f67.google.com with SMTP id j17so1696077pjz.3; Fri, 21 Feb 2020 21:19:16 -0800 (PST) Return-Path: Received: from localhost ([2601:647:4b01:ae80::51fb]) by smtp.gmail.com with ESMTPSA id r62sm4680838pfc.89.2020.02.21.21.19.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Feb 2020 21:19:14 -0800 (PST) Date: Sat, 22 Feb 2020 05:19:00 -0000 From: Fangrui Song To: Mark Wielaard , "H.J. Lu" Cc: Cary Coutant , "Zhang, Annita" , "Liu, Hongtao" , gnu-gabi , GNU C Library , Binutils Subject: Re: binutils ld and new PT_GNU_PROPERTY segment Message-ID: <20200222051913.meiied65a5daylvk@google.com> References: <20200219182701.vrtzwhgtpelmpaub@google.com> <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-SW-Source: 2020-02/txt/msg00512.txt.bz2 + libc-alpha On 2020-02-20, Mark Wielaard wrote: >Hi, > >On Thu, 2020-02-20@03:51 -0800, H.J. Lu wrote: >> On Thu, Feb 20, 2020@1:37 AM Mark Wielaard wrote: >> > On Wed, 2020-02-19@14:17 -0800, H.J. Lu wrote: >> > > >> > > Binaries with .note.gnu.property section have been put into many >> > > OS releases. We must support them. >> > >> > OK. Then it is option 1. The kernel will need to support PT_NOTE for >> > parsing the properties, since such older binaries won't have a >> > PT_GNU_PROPERTY program header. Then we can simply get rid of >> > PT_GNU_PROPERTY since nobody uses it and all information is already >> > available through the PT_NOTE segment. >> > >> >> Kernel loader only checks ld.so and static executable. Re-link them with >> newer linker will get PT_GNU_PROPERTY. But ld.so needs to check >> PT_NOTE for older binaries. > >Having different loaders check different program headers seems very >confusing. And it doesn't really seem to provide backwards >compatibility since depending on how the code was linked previously you >might still require a rebuild. > >Having a mix of PT_NOTE/PT_GNU_PROPERTY segments both based on >SHT_NOTEs, but one of them based on magic section names, makes things >really complicated for other tools. Agreed. The current (glibc: PT_NOTE; proposed Linux: PT_GNU_PROPERTY) mixed mess is looking for trouble. Unfortunately we are likely in a situation where we have to revise ABI[0] just because we did not try hard to get consensus[1][2]. >Please lets either really keep things as they are or redesign things >based on PT_GNU_PROPERTY and a new section type. > >Thanks, > >Mark Below is my understanding of these matters. Hope they will be useful for interested stakeholders (for example, AArch64 devs, though PT_GNU_PROPERTY is currently driven by x86) who don't follow the discussions so closely. 1. We need PT_GNU_PROPERTY. Old linkers don't know the special processing on input .note.gnu.property sections. The output .note.gnu.property does not take -z ibt/-z shstk/-z force-bti/-z pac-plt into account => invalid. The produced PT_NOTE may contain multiple NT_GNU_PROPERTY_TYPE_0 => invalid [3] Also note that sh_addralign(.note.gnu.property)=8 on a 64-bit platform, while sh_addralign(.note.gnu.build-id)=sh_addralign(.note.ABI-tag)=...=4 (ancient mistake made by at least Linux/FreeBSD/NetBSD/...) GNU ld before PR ld/23658 may create corrupted PT_NOTE. For at least the above reasons, loaders are better not interpreting PT_NOTE. glibc/sysdeps/x86/dl-prop.h is currently interpreting PT_NOTE => it should be fixed. Given point 1 and 3, this comment deserves a reconsideration: > Binaries with .note.gnu.property section have been put into many > OS releases. We must support them. 2. .note.gnu.property behaves strangely, unlike a regular SHT_NOTE. For a .note.gnu.property aware linker (newer GNU ld, newer lld), .note.gnu.property input sections are dropped. (We have .note.GNU-stack and .note.GNU-split-stack which both require special processing, but they are SHT_PROGBITS.) 3. We need SHT_GNU_PROPERTY. The output .note.gnu.property being SHT_NOTE causes linkers to place the section in both PT_NOTE and PT_GNU_PROPERTY. PT_NOTE, as explained by point 1 above, can cause trouble to old loaders. Have we proved that "older linker-produced concatenated PT_NOTE cannot cause trouble to loaders interpreting PT_NOTE"? SHT_GNU_PROPERTY does not contribute to PT_NOTE and will not cause any problem to old loaders interpreting PT_NOTE. [0]: https://sourceware.org/ml/gnu-gabi/2018-q4/msg00030.html [1]: https://sourceware.org/ml/gnu-gabi/2018-q4/msg00033.html [2]: https://sourceware.org/ml/gnu-gabi/2018-q4/msg00037.html [3]: https://groups.google.com/forum/#!topic/x86-64-abi/LGPTWbMp8hQ