<div dir="ltr">Peter,<div><br></div><div>Thanks for the great feedback!</div><div><br></div><div>> The first is the use of a custom suffix, all other linker conventions, that I know of, use prefixes as these are much easier and faster to match against names.</div><div>> This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match.<br></div><div>I understand the reason of having these conventions in linkers. On the other hand, there already exists a format with the fixed ".<a href="http://rel.ro" target="_blank">rel.ro</a>" 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"?</div><div><br></div><div>> The second is that you may be able to accomplish what you need with a linker script</div><div>We discussed the possibility of using a custom linker script to achieve that. The main problem is that we're planning to ship the garbage collector as a library. Requiring users to plug in the linker script will be too much of overkill for them and for us. Another problem is that in Chromium we continuously update our toolchain. If there is any change in the default linker script (or logic thereof), we would also have to rebase it on top of our custom one.</div><div><br></div><div>> In principle, if you can get a convention agreed by the ELF linkers then I don't see too much of a problem.</div><div>LLD is the primary linker we use for the most of the platforms we officially support. I wonder, would lld folks be happy if this feature is first implemented as an lld extension and then ported to other linkers as well?</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 27 мар. 2020 г. в 10:06, Peter Smith <<a href="mailto:Peter.Smith@arm.com" target="_blank">Peter.Smith@arm.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Anton,<br>
<br>
> At the moment, all big 3 ELF linkers hardcode names of read-only-after-relocation sections (.<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a>, .<a href="http://bss.rel.ro" rel="noreferrer" target="_blank">bss.rel.ro</a>, .ctors, .eh_frame, ...). We would<br>
> like to propose extending this for custom sections that end with ".<a href="http://rel.ro" rel="noreferrer" target="_blank">rel.ro</a>".<br>
><br>
> What do you think? Would this be useful to you?<br>
<br>
In principle, if you can get a convention agreed by the ELF linkers then I don't see too much of a problem. There are two places I can see where you may get some push back.<br>
<br>
The first is the use of a custom suffix, all other linker conventions, that I know of, use prefixes as these are much easier and faster to match against names. This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match.<br>
<br>
The second is that you may be able to accomplish what you need with a linker script, I'm guessing you don't want to use the existing .data.rel.ro.* convention to take advantage of linker generated symbols. The following example (not tested) assumes a naming convention of .data.rel.ro.RTTI.* in your program.<br>
<br>
.<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a> : {<br>
PROVIDE_HIDDEN (__RTTI_start = .); *(.data.rel.ro.RTTI.*) ; PROVIDE_HIDDEN (__RTTI_end = .);<br>
*(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a> .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }<br>
<br>
This would have your table contiguous in the .<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a> OutputSection and can be found with the __RTTI_start and __RTTI_end symbols. It may not work so well if you are using SHF_LINK_ORDER for the RTTI sections as some linkers tend to handle these better when every InputSection in the OutputSection has SHF_LINK_ORDER.<br>
<br>
Peter<br>
<br>
<br>
________________________________________<br>
From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Anton Bikineev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
Sent: 26 March 2020 19:46<br>
To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
Subject: [llvm-dev] [lld] RFC: Allow custom sections to be under GNU_RELRO<br>
<br>
Hey,<br>
<br>
We would like to propose an idea that would help security harden applications that define custom sections.<br>
<br>
Motivation and Background<br>
In Chromium we have a garbage collector that implements some RTTI machinery in the form of a table. This table is used by the collector to trace and finalize garbage collected objects. We're thinking of using __attribute__((section(...))) so that the table can be created and merged at link time. We also use -fPIC and therefore rely on the dynamic linker to process relocations in this table after the program is loaded. At the same time, we want the table to be read-only after relocations are applied, in the same fashion as e.g. .got sections are write protected after eager binding (with -z,relro,-z,now). The custom section can't be mprotected, because it can live in the same PT_LOAD segment as other modifiable data (e.g. .data).<br>
<br>
At the moment, all big 3 ELF linkers hardcode names of read-only-after-relocation sections (.<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a><<a href="http://data.rel.ro" rel="noreferrer" target="_blank">http://data.rel.ro</a>>, .<a href="http://bss.rel.ro" rel="noreferrer" target="_blank">bss.rel.ro</a><<a href="http://bss.rel.ro" rel="noreferrer" target="_blank">http://bss.rel.ro</a>>, .ctors, .eh_frame, ...). We would like to propose extending this for custom sections that end with ".<a href="http://rel.ro" rel="noreferrer" target="_blank">rel.ro</a><<a href="http://rel.ro" rel="noreferrer" target="_blank">http://rel.ro</a>>".<br>
<br>
What do you think? Would this be useful to you?<br>
<br>
--<br>
Sincerely,<br>
Anton.<br>
</blockquote></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div><div>Sincerely,<br></div>Anton.<br></div></div></div></div>