Re: [PATCH] configure: Use lld --image-base for --disable-pie user mode binaries

[Fangrui Song <i@maskray.me>]

On 2019-12-01, Fangrui Song wrote:
>
>Thanks for reviewing this patch!
>
>On 2019-12-01, Richard Henderson wrote:
>>On 11/27/19 6:36 PM, Fangrui Song wrote:
>>>On 2019-11-20, Fangrui Song wrote:
>>>>On 2019-11-15, Fangrui Song wrote:
>>>>>For lld, --image-base is the preferred way to set the base address.
>>>>>lld does not actually implement -Ttext-segment, but treats it as an alias for
>>>>>-Ttext. -Ttext-segment=0x60000000 combined with --no-rosegment can
>>>>>create a 1.6GB executable.
>>>>>
>>>>>Fix the problem by using --image-base for lld. GNU ld and gold will
>>>>>still get -Ttext-segment. Also delete the ld --verbose fallback introduced
>>>>>in 2013, which is no longer relevant or correct (the default linker
>>>>>script has changed).
>>>>>
>>>>>Signed-off-by: Fangrui Song <i@maskray.me>
>>>>>---
>>>>>configure | 33 ++++++++++++---------------------
>>>>>1 file changed, 12 insertions(+), 21 deletions(-)
>>>>>
>>>>>diff --git a/configure b/configure
>>>>>index 6099be1d84..2d45af0d09 100755
>>>>>--- a/configure
>>>>>+++ b/configure
>>>>>@@ -6336,43 +6336,34 @@ fi
>>>>>
>>>>># Probe for the need for relocating the user-only binary.
>>>>>if ( [ "$linux_user" = yes ] || [ "$bsd_user" = yes ] ) && [ "$pie" = no ];
>>>>>then
>>>>>-  textseg_addr=
>>>>>+  image_base=
>>>>>  case "$cpu" in
>>>>>    arm | i386 | ppc* | s390* | sparc* | x86_64 | x32)
>>>>>-      # ??? Rationale for choosing this address
>>>>>-      textseg_addr=0x60000000
>>>>>+      # An arbitrary address that makes it unlikely to collide with user
>>>>>+      # programs.
>>
>>Please don't replace this ??? with an arbitrary rationale, which clearly
>>doesn't apply to all of these hosts.
>
>In
>https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg04646.html
>it was suggested to move the comment around a bit.
>I am not puzzled where and what I should say in the comment.
>Can you (or other maintainers) kindly edit the comment for me?
>I do not know enough about qemu to provide a good rationale here.
>
>>>>>+      image_base=0x60000000
>>>>>      ;;
>>>>>    mips)
>>>>>      # A 256M aligned address, high in the address space, with enough
>>>>>      # room for the code_gen_buffer above it before the stack.
>>
>>This is the only one with a proper rationale.
>>
>>That said, I'm not sure that the proper way to handle this issue with lld is to
>>drop this code entirely.
>
>The patch changes a feature that lld does not support: -Ttext-segment,
>to use --image-base instead.
>
>Due to the prevalence of -z separate-code in GNU ld, -Ttext-segment is
>no longer appropriate. I suggested that GNU linkers implement the
>feature https://sourceware.org/bugzilla/show_bug.cgi?id=25207 .
>
>What gets deleted is the sed script. As I explained in the commit
>message, it is no longer relevant. It probably applies to an old GNU ld
>that FreeBSD used. FreeBSD has switched to lld now.
>
>>The best way to handle the underlying issue -- address conflict between
>>interpreter and guest binary -- is PIE, for which this code is skipped.
>>
>>After that, we go to some pain to choose a guest_base address that allows the
>>guest binary to load around the interpreter's reserved addresses.
>>
>>So what's left that this messing about with link addresses buys us?
>
>I agree that --enable-pie will be a better solution, but dropping the
>support now will break at least FreeBSD. Its kernel supports running an
>ET_DYN executable but it does not perform address randomization.
>--disable-pie also appears to be used by ChromeOS developers who
>reported https://bugs.llvm.org/show_bug.cgi?id=43997 . I can communicate
>to them that migrating to --enable-pie is the way going forward.

Ping? There is another very good reason that we need to keep
--disable-pie for a while. Many users build statically linked qemu user
mode binaries. -static-pie requires newer toolchain:

* GCC 8 or clang 9
* binutils>=2.29
* glibc>=2.27 or musl

Dropping support for GCC<8 does not sound a good idea in the year of 2019. (It may be in a few years.)