lkml.org 
[lkml]   [2020]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: --orphan-handling=warn
On Mon, Feb 24, 2020 at 09:35:04PM -0800, Kees Cook wrote:
>
> Actually, it's rather opposed to the FGKASLR series, as for that, I need
> some kind of linker script directive like this:
>
> /PASSTHRU/ : {
> *(.text.*)
> }
>
> Where "PASSTHRU" would create a 1-to-1 input-section to output-section
> with the same name, flags, etc.
>
> ld.bfd's handling of orphan sections named .text.* is to put them each
> as a separate output section, after the existing .text output section.
>
> ld.lld's handling of orphan sections named .text.* is to put them into
> the .text output section.

This doesn't match ld's documentation [1] of how orphan sections are to
be handled, it's supposed to append it into an existing output section
only if the names match exactly, creating a new one if that isn't so. If
ld.lld is to be a drop-in replacement for ld.bfd, this probably needs to
change?

Also ld.lld doesn't seem to support the --unique option, I think you'll
also want that for FGKASLR to avoid merging static functions with the
same name from unrelated source files.

[1] https://sourceware.org/binutils/docs/ld/Orphan-Sections.html

>
> For FGKASLR (as it is currently implemented[2]), the sections need to be
> individually named output sections (as bfd does it). *However*, with the
> "warn on orphans" patch, FGKASLR's intentional orphaning will backfire
> (I guess the warning could be turned off, but I'd like lld to handle
> FGKASLR at some point.)
>
> Note that cheating and doing the 1-to-1 mapping by handy with a 40,000
> entry linker script ... made ld.lld take about 15 minutes to do the
> final link. :(

Out of curiosity, how long does ld.bfd take on that linker script :)

\
 
 \ /
  Last update: 2020-02-25 19:30    [W:1.613 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site