* Re: binutils ld and new PT_GNU_PROPERTY segment [not found] ` <a6752f00b3e0e0eb799c840b3b991a9730c9c86b.camel@klomp.org> @ 2020-02-22 5:19 ` Fangrui Song 2020-04-01 8:46 ` Florian Weimer 0 siblings, 1 reply; 6+ messages in thread From: Fangrui Song @ 2020-02-22 5:19 UTC (permalink / raw) To: Mark Wielaard, H.J. Lu Cc: Cary Coutant, Zhang, Annita, Liu, Hongtao, gnu-gabi, GNU C Library, Binutils + 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils ld and new PT_GNU_PROPERTY segment 2020-02-22 5:19 ` binutils ld and new PT_GNU_PROPERTY segment Fangrui Song @ 2020-04-01 8:46 ` Florian Weimer 2020-04-01 9:22 ` Szabolcs Nagy 0 siblings, 1 reply; 6+ messages in thread From: Florian Weimer @ 2020-04-01 8:46 UTC (permalink / raw) To: Fangrui Song Cc: Mark Wielaard, H.J. Lu, Cary Coutant, Zhang, Annita, Liu, Hongtao, gnu-gabi, GNU C Library, Binutils * Fangrui Song: > 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] In practice, we can recognize binaries produced by old linkers when the object has been linked on a CET-enabled distribution because the produced notes are always invalid. The glibc dynamic loader already checks for this and does not enable CET in this case. ld -r involving exactly one CET-enabled object and one or more non-CET objects is still problematic, of course, but it seems an unlikely outcome. The only way I can see this happening is with a CET-by-default GCC (such as the one Ubuntu uses), but then you still would have to use another linker (not /usr/bin/ld). So even that seems like a fringe issue to me. In short, we looked at this situation, and still think that it's supportable. > 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. Yes, we ran into some of these issues in our distribution and had to rebuild a few objects. > 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. I'm not sure we can do that for backwards compatibility reasons. The ABI has been out there for several years now. > 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. Yes, I agree that it's desirable to add SHT_GNU_PROPERTY. Thanks, Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils ld and new PT_GNU_PROPERTY segment 2020-04-01 8:46 ` Florian Weimer @ 2020-04-01 9:22 ` Szabolcs Nagy 2020-04-01 9:29 ` Florian Weimer 0 siblings, 1 reply; 6+ messages in thread From: Szabolcs Nagy @ 2020-04-01 9:22 UTC (permalink / raw) To: Florian Weimer Cc: Fangrui Song, GNU C Library, gnu-gabi, Mark Wielaard, Zhang, Annita, Binutils, Cary Coutant, Liu, Hongtao The 04/01/2020 10:46, Florian Weimer via Libc-alpha wrote: > * Fangrui Song: > > > 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] > > In practice, we can recognize binaries produced by old linkers when the > object has been linked on a CET-enabled distribution because the > produced notes are always invalid. The glibc dynamic loader already > checks for this and does not enable CET in this case. > > ld -r involving exactly one CET-enabled object and one or more non-CET > objects is still problematic, of course, but it seems an unlikely > outcome. The only way I can see this happening is with a CET-by-default > GCC (such as the one Ubuntu uses), but then you still would have to use > another linker (not /usr/bin/ld). So even that seems like a fringe > issue to me. why only -r is problematic? i thought linking exactly one marked object and other non-marked ones with an old linker will have the (incorrect) marking on the output that cannot be recognised as wrong. this is why my plan for aarch64 is to only check PT_GNU_PROPERTY in glibc (which implies a new linker), i believe the kernel patches do so too. > > In short, we looked at this situation, and still think that it's > supportable. > > > 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. > > Yes, we ran into some of these issues in our distribution and had to > rebuild a few objects. > > > 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. > > I'm not sure we can do that for backwards compatibility reasons. The > ABI has been out there for several years now. on non-x86 targets it can be still done. > > 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. > > Yes, I agree that it's desirable to add SHT_GNU_PROPERTY. +1 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils ld and new PT_GNU_PROPERTY segment 2020-04-01 9:22 ` Szabolcs Nagy @ 2020-04-01 9:29 ` Florian Weimer 2020-04-01 10:10 ` Szabolcs Nagy 0 siblings, 1 reply; 6+ messages in thread From: Florian Weimer @ 2020-04-01 9:29 UTC (permalink / raw) To: Szabolcs Nagy Cc: Fangrui Song, GNU C Library, gnu-gabi, Mark Wielaard, Zhang, Annita, Binutils, Cary Coutant, Liu, Hongtao * Szabolcs Nagy: > why only -r is problematic? > > i thought linking exactly one marked object and other non-marked > ones with an old linker will have the (incorrect) marking on the > output that cannot be recognised as wrong. Where do you get that single marked object? If you are on a CET-enabled distribution, the startup files are marked, so you have multiple marked objects right there. >> I'm not sure we can do that for backwards compatibility reasons. The >> ABI has been out there for several years now. > > on non-x86 targets it can be still done. That's true. Thanks, Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils ld and new PT_GNU_PROPERTY segment 2020-04-01 9:29 ` Florian Weimer @ 2020-04-01 10:10 ` Szabolcs Nagy 2020-04-01 10:21 ` Florian Weimer 0 siblings, 1 reply; 6+ messages in thread From: Szabolcs Nagy @ 2020-04-01 10:10 UTC (permalink / raw) To: Florian Weimer Cc: Fangrui Song, GNU C Library, gnu-gabi, Mark Wielaard, Zhang, Annita, Binutils, Cary Coutant, Liu, Hongtao The 04/01/2020 11:29, Florian Weimer wrote: > * Szabolcs Nagy: > > why only -r is problematic? > > > > i thought linking exactly one marked object and other non-marked > > ones with an old linker will have the (incorrect) marking on the > > output that cannot be recognised as wrong. > > Where do you get that single marked object? > > If you are on a CET-enabled distribution, the startup files are marked, > so you have multiple marked objects right there. assume your toolchain is not cet enabled (and has an old linker) but you link in a library archive that is cet enabled (because it was given to you that way) and exactly one .o from it gets used during the link. the resulting binary will have the marking and if deployed on a cet enabled system it won't work. (at least this is my current understanding.) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: binutils ld and new PT_GNU_PROPERTY segment 2020-04-01 10:10 ` Szabolcs Nagy @ 2020-04-01 10:21 ` Florian Weimer 0 siblings, 0 replies; 6+ messages in thread From: Florian Weimer @ 2020-04-01 10:21 UTC (permalink / raw) To: Szabolcs Nagy Cc: Fangrui Song, GNU C Library, gnu-gabi, Mark Wielaard, Zhang, Annita, Binutils, Cary Coutant, Liu, Hongtao * Szabolcs Nagy: > The 04/01/2020 11:29, Florian Weimer wrote: >> * Szabolcs Nagy: >> > why only -r is problematic? >> > >> > i thought linking exactly one marked object and other non-marked >> > ones with an old linker will have the (incorrect) marking on the >> > output that cannot be recognised as wrong. >> >> Where do you get that single marked object? >> >> If you are on a CET-enabled distribution, the startup files are marked, >> so you have multiple marked objects right there. > > assume your toolchain is not cet enabled (and has an old > linker) but you link in a library archive that is cet > enabled (because it was given to you that way) and exactly > one .o from it gets used during the link. > > the resulting binary will have the marking and if deployed > on a cet enabled system it won't work. (at least this is > my current understanding.) But that's not something we currently support. We do not have ABI stability for static linking like this. You are more likely to run into problems due to other issues (e.g., missing glibc symbols) than incorrect CET markup. Thanks, Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-01 10:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAMe9rOpgwi0M9XqbeyUm+LLuqypObZBmEGEAgFAyDeUYck5ucA@mail.gmail.com>
[not found] ` <df471f18bee6c4dcdb40c284aac719524f1ad148.camel@klomp.org>
[not found] ` <CAMe9rOr7=hYan1h=4BmqZ9Ep8dou_E_BBg0UjXBavi6x4cTWZA@mail.gmail.com>
[not found] ` <20200219182701.vrtzwhgtpelmpaub@google.com>
[not found] ` <CAMe9rOrWFu9QUb_q6UjaH5Av_CMoBCaXCj1Z_chUTDqQ4YaY=g@mail.gmail.com>
[not found] ` <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org>
[not found] ` <CAMe9rOoqH9kQ7ipiYWZPV4mwyKNU-k+TRX53E-ZNokOps2bpsg@mail.gmail.com>
[not found] ` <f661f98effcc200f28c3e64e6bc40bb5ae60c5a5.camel@klomp.org>
[not found] ` <CAMe9rOpWbU=rMb62mgqLFsHFTHfq8VQO7BfG4Codkrqh_b1x5Q@mail.gmail.com>
[not found] ` <a6752f00b3e0e0eb799c840b3b991a9730c9c86b.camel@klomp.org>
2020-02-22 5:19 ` binutils ld and new PT_GNU_PROPERTY segment Fangrui Song
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
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).