From: Fangrui Song <i@maskray.me>
To: Mark Wielaard <mark@klomp.org>, "H.J. Lu" <hjl.tools@gmail.com>
Cc: Cary Coutant <ccoutant@gmail.com>,
"Zhang, Annita" <annita.zhang@intel.com>,
"Liu, Hongtao" <hongtao.liu@intel.com>,
gnu-gabi <gnu-gabi@sourceware.org>,
GNU C Library <libc-alpha@sourceware.org>,
Binutils <binutils@sourceware.org>
Subject: Re: binutils ld and new PT_GNU_PROPERTY segment
Date: Wed, 01 Jan 2020 00:00:00 -0000 [thread overview]
Message-ID: <20200222051913.meiied65a5daylvk@google.com> (raw)
In-Reply-To: <a6752f00b3e0e0eb799c840b3b991a9730c9c86b.camel@klomp.org>
+ 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 <mark@klomp.org> 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
next prev parent reply other threads:[~2020-02-22 5:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-01 0:00 Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` Fangrui Song via gnu-gabi
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` Fangrui Song [this message]
2020-04-01 8:46 ` Florian Weimer
2020-04-01 9:22 ` Szabolcs Nagy
2020-04-01 9:29 ` Florian Weimer
2020-04-01 10:10 ` Szabolcs Nagy
2020-04-01 10:21 ` Florian Weimer
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Zhang, Annita
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200222051913.meiied65a5daylvk@google.com \
--to=i@maskray.me \
--cc=annita.zhang@intel.com \
--cc=binutils@sourceware.org \
--cc=ccoutant@gmail.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=hongtao.liu@intel.com \
--cc=libc-alpha@sourceware.org \
--cc=mark@klomp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).