Re: [ld] Allow custom sections to be under PT_GNU_RELRO

[Fangrui Song <i@maskray.me>]

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.