qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fangrui Song
Subject: Re: [PATCH] configure: Use lld --image-base for --disable-pie user mode binaries
Date: Mon, 9 Dec 2019 23:10:30 -0800

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 <address@hidden>
---
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.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]