From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34225 invoked by alias); 22 Feb 2020 05:19: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 34194 invoked by uid 89); 22 Feb 2020 05:19:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No 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-Spam-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 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 3 recipients 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zCb+f3Dhl2lzv2FytYsg3Y+uGzGAUtLCnhg8EvEhx8U=; b=YRCjiaQWL7plWfgxe7WilYuVR3EYaeKGaIefSqpb3+PKx7QzeJ8gY/NOGVq6K7Xt8x jbUdOHJvUs7t9jXYGXyjF2b6fUqj6Wq92o0L/qFX974lPxRx/pyszMz59LnTP7Yv5xEx gWDe/qWViPWgVZgWzi02iI12Z7itHMHoOEBA9lvBmfIsc0Ww1H8dozfcRN3JDssjg7Ed IBZvar7cOtawirx+62oo2pYWAEQvqTRZeB9Wwg93YaekZNreEM6UYKY5PglWB0pkrPL/ ozp5vly4K20bPFlautY1C9GunTb029IPDmsKX5MkOZxrdEoQbhEbCgohQh8uNxTHlSM1 nWyA== X-Gm-Message-State: APjAAAXzjAUWxpJNWxQZ2RyDl78aOb1lgduzrAUiJg8gZMCoUntrCGla 0RDF26qm0OI7Ha9K808bvFeUMexq X-Google-Smtp-Source: APXvYqyY/wf/GGO9esEhrllSZIq/gIz0U9C4Jv+SDTe4zWqf/t55Xr43RU5YWTQp0//C4rvld6xUng== X-Received: by 2002:a17:90a:cb8c:: with SMTP id a12mr7367591pju.71.1582348755209; Fri, 21 Feb 2020 21:19:15 -0800 (PST) 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: Wed, 01 Jan 2020 00:00: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-q1/txt/msg00021.txt + 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