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

[Fangrui Song <i@maskray.me>]

On 2019-12-09, Fangrui Song wrote:
>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.)

Ping...