* [ld] Allow custom sections to be under PT_GNU_RELRO
@ 2020-03-28 4:22 Fangrui Song
2020-03-28 10:05 ` Florian Weimer
0 siblings, 1 reply; 8+ messages in thread
From: Fangrui Song @ 2020-03-28 4:22 UTC (permalink / raw)
To: binutils
https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html
> I understand the reason of having these conventions in linkers. On the
other hand, there already exists a format with the fixed ".rel.ro"
suffix for .data and .bss. Custom suffixes would also mean that the user
code would depend more on implementation-specific things, i.e. prefixes.
For example, one would wonder, should they annotate their data with
__attribute__((section(...))) for ".data.rel.ro.my_section" or
".bss.rel.ro.my_section"?
What do you think of the magic ".rel.ro" idea?
I am not convinced this is a good idea yet but this proposal looks
interesting and I'd like to hear some other thoughts.
For the implementation, I guess this may require some logic in ld/ldelf.c:ldelf_place_orphan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-03-28 4:22 [ld] Allow custom sections to be under PT_GNU_RELRO Fangrui Song @ 2020-03-28 10:05 ` Florian Weimer 2020-04-07 0:28 ` Cary Coutant 0 siblings, 1 reply; 8+ messages in thread From: Florian Weimer @ 2020-03-28 10:05 UTC (permalink / raw) To: Fangrui Song; +Cc: binutils * Fangrui Song: > https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html > > I understand the reason of having these conventions in linkers. On the > other hand, there already exists a format with the fixed ".rel.ro" > suffix for .data and .bss. Custom suffixes would also mean that the user > code would depend more on implementation-specific things, i.e. prefixes. > For example, one would wonder, should they annotate their data with > __attribute__((section(...))) for ".data.rel.ro.my_section" or > ".bss.rel.ro.my_section"? > > What do you think of the magic ".rel.ro" idea? We could sacrifice a section flag for this. The feature may be sufficiently important for that. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-03-28 10:05 ` Florian Weimer @ 2020-04-07 0:28 ` Cary Coutant 2020-04-07 2:51 ` Fangrui Song 0 siblings, 1 reply; 8+ messages in thread From: Cary Coutant @ 2020-04-07 0:28 UTC (permalink / raw) To: Florian Weimer Cc: Fangrui Song, Binutils, Generic System V Application Binary Interface > > https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html > > > > I understand the reason of having these conventions in linkers. On the > > other hand, there already exists a format with the fixed ".rel.ro" > > suffix for .data and .bss. Custom suffixes would also mean that the user > > code would depend more on implementation-specific things, i.e. prefixes. > > For example, one would wonder, should they annotate their data with > > __attribute__((section(...))) for ".data.rel.ro.my_section" or > > ".bss.rel.ro.my_section"? > > > > What do you think of the magic ".rel.ro" idea? > > We could sacrifice a section flag for this. The feature may be > sufficiently important for that. My first reaction was: Do you *really* need to use a new custom section name? But after reading through the thread on the LLVM list, I see why -- you want the RTTI-like sections to be contiguous within the RELRO segment. The gold sources have this comment: // With -z relro, we have to recognize the special sections by name. // There is no other way. String matching on the section name is ugly and a performance hit whether it's a fixed section name (as it is now), a prefix, or a suffix. Yes, it should have been done with a flag from the beginning. Theoretically, we might not even have needed a new flag. If the compiler would mark RELRO sections as read-only, the linker could look for read-only, non-executable sections with dynamic relocations, and mark them as RELRO, or simply turn on SHF_WRITE for -z norelro. But that would break under older linkers, so it was much better from a compatibility standpoint to mark RELRO sections as writable, meaning there has to be some other way of recognizing that they're really read-only but for the relocations. It may also have made things difficult for the linker, requiring a scan over the relocations before deciding where to place the section (I haven't looked carefully to see if that would be a problem in gold). Starting from where we are now, I'd say we need an SHF_RELRO flag, and compilers should start setting that flag on .data.rel.ro and .data.rel.ro.local sections. Linkers should treat all .data.rel.ro and .data.rel.ro.local sections as if the flag were set, regardless. Maybe in 10-20 years, we can finally take those strcmp's out. Any sections marked SHF_RELRO should also be marked SHF_WRITE, for compatibility with older linkers and to make it simpler to ignore the flag in the -z norelro case. I'd probably also want to require that they NOT be SHF_EXECINSTR. That probably also means that we should graduate PT_GNU_RELRO to the gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ entries in the dynamic table. (I kind of prefer the dynamic table over the program header table for things like this, since it's the dynamic linker, not the kernel loader, that needs to know about it.) -cary ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-04-07 0:28 ` Cary Coutant @ 2020-04-07 2:51 ` Fangrui Song 2020-04-07 3:18 ` Fangrui Song 2020-04-07 16:28 ` Cary Coutant 0 siblings, 2 replies; 8+ messages in thread From: Fangrui Song @ 2020-04-07 2:51 UTC (permalink / raw) To: Cary Coutant, Florian Weimer Cc: Binutils, Generic System V Application Binary Interface On 2020-04-06, Cary Coutant wrote: >> > https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html >> > >> > I understand the reason of having these conventions in linkers. On the >> > other hand, there already exists a format with the fixed ".rel.ro" >> > suffix for .data and .bss. Custom suffixes would also mean that the user >> > code would depend more on implementation-specific things, i.e. prefixes. >> > For example, one would wonder, should they annotate their data with >> > __attribute__((section(...))) for ".data.rel.ro.my_section" or >> > ".bss.rel.ro.my_section"? >> > >> > What do you think of the magic ".rel.ro" idea? >> >> We could sacrifice a section flag for this. The feature may be >> sufficiently important for that. > >My first reaction was: Do you *really* need to use a new custom >section name? But after reading through the thread on the LLVM list, I >see why -- you want the RTTI-like sections to be contiguous within the >RELRO segment. > >The gold sources have this comment: > > // With -z relro, we have to recognize the special sections by name. > // There is no other way. > >String matching on the section name is ugly and a performance hit >whether it's a fixed section name (as it is now), a prefix, or a >suffix. Yes, it should have been done with a flag from the beginning. > >Theoretically, we might not even have needed a new flag. If the >compiler would mark RELRO sections as read-only, the linker could look >for read-only, non-executable sections with dynamic relocations, and >mark them as RELRO, or simply turn on SHF_WRITE for -z norelro. But >that would break under older linkers, so it was much better from a >compatibility standpoint to mark RELRO sections as writable, meaning >there has to be some other way of recognizing that they're really >read-only but for the relocations. It may also have made things >difficult for the linker, requiring a scan over the relocations before >deciding where to place the section (I haven't looked carefully to see >if that would be a problem in gold). > >Starting from where we are now, I'd say we need an SHF_RELRO flag, and >compilers should start setting that flag on .data.rel.ro and >.data.rel.ro.local sections. Linkers should treat all .data.rel.ro and >.data.rel.ro.local sections as if the flag were set, regardless. Maybe >in 10-20 years, we can finally take those strcmp's out. > >Any sections marked SHF_RELRO should also be marked SHF_WRITE, for >compatibility with older linkers and to make it simpler to ignore the >flag in the -z norelro case. I'd probably also want to require that >they NOT be SHF_EXECINSTR. Your SHF_RELRO scheme (implies SHF_WRITE; can't be used together with SHF_EXECINSTR) looks fine with me. I suppose we will assign 0x1000 to SHF_RELRO. It looks like GNU ld, gold and LLD all happily accept the unknown flag 0x1000 (.text .tdata .tbss ...). GNU ld and gold will not keep 0x1000 from the output section flags, though. Hope Solaris/HP-UX toolchain experts can answer the question about their linkers. Should SHF_TLS imply SHF_RELRO? >That probably also means that we should graduate PT_GNU_RELRO to the >gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ >entries in the dynamic table. (I kind of prefer the dynamic table over >the program header table for things like this, since it's the dynamic >linker, not the kernel loader, that needs to know about it.) > >-cary I can foresee people's objection to depriving one value 0x6474e552 from the PT_LOOS~PT_HIOS range. (See a recent discussion https://groups.google.com/forum/#!msg/x86-64-abi/7sr4E6THl3g/zUU2UPHOAQAJ "RFC: Usefulness of SHT_X86_64_UNWIND") Your argument made me convinced that DT_RELRO/DT_RELROSZ is better than PT_RELRO. Though I also foresee people's objection that this will make the design not readily usable. Perhaps we should bite the bullet. The parties which are mostly interested in this feature may have a good control of their ld.so. So, for linker/loader implementations, when a SHF_RELRO is seen, DT_RELRO/DT_RELROSZ should be used and PT_GNU_RELRO should disappear. If we can reach progress on the proposal, I will be happy to implement the feature on LLD/clang integrated assembler/llvm-readobj/llvm-objdump side. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-04-07 2:51 ` Fangrui Song @ 2020-04-07 3:18 ` Fangrui Song 2020-04-07 6:10 ` Fangrui Song 2020-04-07 16:28 ` Cary Coutant 1 sibling, 1 reply; 8+ messages in thread From: Fangrui Song @ 2020-04-07 3:18 UTC (permalink / raw) To: Cary Coutant, Florian Weimer; +Cc: Binutils Drop Generic System V Application Binary Interface <generic-abi@googlegroups.com> A non-subscribed email address will get a bounce. We're writing to let you know that the group you tried to contact (generic-abi) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post: * You might have spelled or formatted the group name incorrectly. * The owner of the group may have removed this group. * You may need to join the group before receiving permission to post. * This group may not be open to posting. If you have questions related to this or any other Google Group, visit the Help Center at https://groups.google.com/support/. On 2020-04-06, Fangrui Song wrote: >On 2020-04-06, Cary Coutant wrote: >>>> https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html >>>> >>>> I understand the reason of having these conventions in linkers. On the >>>> other hand, there already exists a format with the fixed ".rel.ro" >>>> suffix for .data and .bss. Custom suffixes would also mean that the user >>>> code would depend more on implementation-specific things, i.e. prefixes. >>>> For example, one would wonder, should they annotate their data with >>>> __attribute__((section(...))) for ".data.rel.ro.my_section" or >>>> ".bss.rel.ro.my_section"? >>>> >>>> What do you think of the magic ".rel.ro" idea? >>> >>>We could sacrifice a section flag for this. The feature may be >>>sufficiently important for that. >> >>My first reaction was: Do you *really* need to use a new custom >>section name? But after reading through the thread on the LLVM list, I >>see why -- you want the RTTI-like sections to be contiguous within the >>RELRO segment. >> >>The gold sources have this comment: >> >> // With -z relro, we have to recognize the special sections by name. >> // There is no other way. >> >>String matching on the section name is ugly and a performance hit >>whether it's a fixed section name (as it is now), a prefix, or a >>suffix. Yes, it should have been done with a flag from the beginning. >> >>Theoretically, we might not even have needed a new flag. If the >>compiler would mark RELRO sections as read-only, the linker could look >>for read-only, non-executable sections with dynamic relocations, and >>mark them as RELRO, or simply turn on SHF_WRITE for -z norelro. But >>that would break under older linkers, so it was much better from a >>compatibility standpoint to mark RELRO sections as writable, meaning >>there has to be some other way of recognizing that they're really >>read-only but for the relocations. It may also have made things >>difficult for the linker, requiring a scan over the relocations before >>deciding where to place the section (I haven't looked carefully to see >>if that would be a problem in gold). >> >>Starting from where we are now, I'd say we need an SHF_RELRO flag, and >>compilers should start setting that flag on .data.rel.ro and >>.data.rel.ro.local sections. Linkers should treat all .data.rel.ro and >>.data.rel.ro.local sections as if the flag were set, regardless. Maybe >>in 10-20 years, we can finally take those strcmp's out. >> >>Any sections marked SHF_RELRO should also be marked SHF_WRITE, for >>compatibility with older linkers and to make it simpler to ignore the >>flag in the -z norelro case. I'd probably also want to require that >>they NOT be SHF_EXECINSTR. > >Your SHF_RELRO scheme (implies SHF_WRITE; can't be used together with >SHF_EXECINSTR) looks fine with me. > >I suppose we will assign 0x1000 to SHF_RELRO. It looks like GNU ld, gold >and LLD all happily accept the unknown flag 0x1000 (.text .tdata .tbss >...). GNU ld and gold will not keep 0x1000 from the output section >flags, though. Hope Solaris/HP-UX toolchain experts can answer the >question about their linkers. > >Should SHF_TLS imply SHF_RELRO? > >>That probably also means that we should graduate PT_GNU_RELRO to the >>gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ >>entries in the dynamic table. (I kind of prefer the dynamic table over >>the program header table for things like this, since it's the dynamic >>linker, not the kernel loader, that needs to know about it.) >> >>-cary > >I can foresee people's objection to depriving one value 0x6474e552 from >the PT_LOOS~PT_HIOS range. (See a recent discussion >https://groups.google.com/forum/#!msg/x86-64-abi/7sr4E6THl3g/zUU2UPHOAQAJ "RFC: Usefulness of SHT_X86_64_UNWIND") > > >Your argument made me convinced that DT_RELRO/DT_RELROSZ is better than >PT_RELRO. Though I also foresee people's objection that this will make >the design not readily usable. Perhaps we should bite the bullet. The >parties which are mostly interested in this feature may have a good >control of their ld.so. > >So, for linker/loader implementations, when a SHF_RELRO is seen, >DT_RELRO/DT_RELROSZ should be used and PT_GNU_RELRO should disappear. > >If we can reach progress on the proposal, I will be happy to implement >the feature on LLD/clang integrated assembler/llvm-readobj/llvm-objdump side. Ali Bahrami rejected SHF_RELRO. https://groups.google.com/d/msg/generic-abi/eXcc0_1KF98/vGbWuVdWCAAJ We can still do SHF_GNU_RELRO and DT_GNU_RELRO/DT_GNU_RELROSZ. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-04-07 3:18 ` Fangrui Song @ 2020-04-07 6:10 ` Fangrui Song 2020-04-07 16:37 ` Cary Coutant 0 siblings, 1 reply; 8+ messages in thread From: Fangrui Song @ 2020-04-07 6:10 UTC (permalink / raw) To: Cary Coutant, Florian Weimer; +Cc: Binutils, gnu-gabi On 2020-04-06, Fangrui Song wrote: >Drop Generic System V Application Binary Interface <generic-abi@googlegroups.com> > >A non-subscribed email address will get a bounce. > > We're writing to let you know that the group you tried to contact (generic-abi) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post: > * You might have spelled or formatted the group name incorrectly. > * The owner of the group may have removed this group. > * You may need to join the group before receiving permission to post. > * This group may not be open to posting. > If you have questions related to this or any other Google Group, visit the Help Center at https://groups.google.com/support/. > >On 2020-04-06, Fangrui Song wrote: >>On 2020-04-06, Cary Coutant wrote: >>>>>https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html >>>>> >>>>>I understand the reason of having these conventions in linkers. On the >>>>>other hand, there already exists a format with the fixed ".rel.ro" >>>>>suffix for .data and .bss. Custom suffixes would also mean that the user >>>>>code would depend more on implementation-specific things, i.e. prefixes. >>>>>For example, one would wonder, should they annotate their data with >>>>>__attribute__((section(...))) for ".data.rel.ro.my_section" or >>>>>".bss.rel.ro.my_section"? >>>>> >>>>>What do you think of the magic ".rel.ro" idea? >>>> >>>>We could sacrifice a section flag for this. The feature may be >>>>sufficiently important for that. >>> >>>My first reaction was: Do you *really* need to use a new custom >>>section name? But after reading through the thread on the LLVM list, I >>>see why -- you want the RTTI-like sections to be contiguous within the >>>RELRO segment. >>> >>>The gold sources have this comment: >>> >>>// With -z relro, we have to recognize the special sections by name. >>>// There is no other way. >>> >>>String matching on the section name is ugly and a performance hit >>>whether it's a fixed section name (as it is now), a prefix, or a >>>suffix. Yes, it should have been done with a flag from the beginning. >>> >>>Theoretically, we might not even have needed a new flag. If the >>>compiler would mark RELRO sections as read-only, the linker could look >>>for read-only, non-executable sections with dynamic relocations, and >>>mark them as RELRO, or simply turn on SHF_WRITE for -z norelro. But >>>that would break under older linkers, so it was much better from a >>>compatibility standpoint to mark RELRO sections as writable, meaning >>>there has to be some other way of recognizing that they're really >>>read-only but for the relocations. It may also have made things >>>difficult for the linker, requiring a scan over the relocations before >>>deciding where to place the section (I haven't looked carefully to see >>>if that would be a problem in gold). >>> >>>Starting from where we are now, I'd say we need an SHF_RELRO flag, and >>>compilers should start setting that flag on .data.rel.ro and >>>.data.rel.ro.local sections. Linkers should treat all .data.rel.ro and >>>.data.rel.ro.local sections as if the flag were set, regardless. Maybe >>>in 10-20 years, we can finally take those strcmp's out. >>> >>>Any sections marked SHF_RELRO should also be marked SHF_WRITE, for >>>compatibility with older linkers and to make it simpler to ignore the >>>flag in the -z norelro case. I'd probably also want to require that >>>they NOT be SHF_EXECINSTR. >> >>Your SHF_RELRO scheme (implies SHF_WRITE; can't be used together with >>SHF_EXECINSTR) looks fine with me. >> >>I suppose we will assign 0x1000 to SHF_RELRO. It looks like GNU ld, gold >>and LLD all happily accept the unknown flag 0x1000 (.text .tdata .tbss >>...). GNU ld and gold will not keep 0x1000 from the output section >>flags, though. Hope Solaris/HP-UX toolchain experts can answer the >>question about their linkers. >> >>Should SHF_TLS imply SHF_RELRO? >> >>>That probably also means that we should graduate PT_GNU_RELRO to the >>>gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ >>>entries in the dynamic table. (I kind of prefer the dynamic table over >>>the program header table for things like this, since it's the dynamic >>>linker, not the kernel loader, that needs to know about it.) >>> >>>-cary >> >>I can foresee people's objection to depriving one value 0x6474e552 from >>the PT_LOOS~PT_HIOS range. (See a recent discussion >>https://groups.google.com/forum/#!msg/x86-64-abi/7sr4E6THl3g/zUU2UPHOAQAJ "RFC: Usefulness of SHT_X86_64_UNWIND") >> >> >>Your argument made me convinced that DT_RELRO/DT_RELROSZ is better than >>PT_RELRO. Though I also foresee people's objection that this will make >>the design not readily usable. Perhaps we should bite the bullet. The >>parties which are mostly interested in this feature may have a good >>control of their ld.so. >> >>So, for linker/loader implementations, when a SHF_RELRO is seen, >>DT_RELRO/DT_RELROSZ should be used and PT_GNU_RELRO should disappear. >> >>If we can reach progress on the proposal, I will be happy to implement >>the feature on LLD/clang integrated assembler/llvm-readobj/llvm-objdump side. > >Ali Bahrami rejected SHF_RELRO. >https://groups.google.com/d/msg/generic-abi/eXcc0_1KF98/vGbWuVdWCAAJ > >We can still do SHF_GNU_RELRO and DT_GNU_RELRO/DT_GNU_RELROSZ. Looks like neither Solaris nor HP-UX likes the generic SHF_RELRO (https://groups.google.com/forum/#!topic/generic-abi/eXcc0_1KF98) We can make it SHF_GNU_RELRO now. For that case, inventing new stuff DT_GNU_RELRO/DT_GNU_RELROSZ is not really meaningful. Rich Felker reminded me that this is about how segments are mapped/protected. PT_* (the current design) is more appropriate. We can define: SHF_GNU_RELRO = 0x100000 (under SHF_MASKOS) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-04-07 6:10 ` Fangrui Song @ 2020-04-07 16:37 ` Cary Coutant 0 siblings, 0 replies; 8+ messages in thread From: Cary Coutant @ 2020-04-07 16:37 UTC (permalink / raw) To: Fangrui Song; +Cc: Florian Weimer, Binutils, gnu-gabi > For that case, inventing new stuff DT_GNU_RELRO/DT_GNU_RELROSZ is not > really meaningful. Rich Felker reminded me that this is about how > segments are mapped/protected. PT_* (the current design) is more > appropriate. I disagree with this, but not strongly. I believe that the program header table entries are for the kernel loader, and the more things we add there for the dynamic loader means more spam that the kernel loader has to sift through. Of course, PT_DYNAMIC is needed, but once we have that, the dynamic loader can find everything else it needs in the dynamic table. I think PT_xxx_UNWIND probably should have been a pair of dynamic table entries, too (that might fit in with Rich's logic). If I were designing ELF from scratch, I'd be tempted to combine the program header table and the dynamic table into one, perhaps partitioning it so that kernel-significant entries all come first. -cary ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ld] Allow custom sections to be under PT_GNU_RELRO 2020-04-07 2:51 ` Fangrui Song 2020-04-07 3:18 ` Fangrui Song @ 2020-04-07 16:28 ` Cary Coutant 1 sibling, 0 replies; 8+ messages in thread From: Cary Coutant @ 2020-04-07 16:28 UTC (permalink / raw) To: Fangrui Song Cc: Florian Weimer, Binutils, Generic System V Application Binary Interface > >That probably also means that we should graduate PT_GNU_RELRO to the > >gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ > >entries in the dynamic table. (I kind of prefer the dynamic table over > >the program header table for things like this, since it's the dynamic > >linker, not the kernel loader, that needs to know about it.) > > I can foresee people's objection to depriving one value 0x6474e552 from > the PT_LOOS~PT_HIOS range. (See a recent discussion > https://groups.google.com/forum/#!msg/x86-64-abi/7sr4E6THl3g/zUU2UPHOAQAJ "RFC: Usefulness of SHT_X86_64_UNWIND") I didn't mean to imply using the existing PT_GNU_RELRO value. Of course I'd assign a new value in the gABI range. But this is moot, as it seems the consensus is that RELRO should remain a GNU extension. -cary ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-04-07 16:37 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-28 4:22 [ld] Allow custom sections to be under PT_GNU_RELRO Fangrui Song 2020-03-28 10:05 ` Florian Weimer 2020-04-07 0:28 ` Cary Coutant 2020-04-07 2:51 ` Fangrui Song 2020-04-07 3:18 ` Fangrui Song 2020-04-07 6:10 ` Fangrui Song 2020-04-07 16:37 ` Cary Coutant 2020-04-07 16:28 ` Cary Coutant
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).