Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]

[Florian Weimer <fw@deneb.enyo.de>]

* H. J. Lu:

> The GCC driver patch has been checked into GCC 8.   Here is the updated
> patch for glibc.
>
> Tested with build-many-glibcs.py.    Any objections?

Is the entire text below supposed to go into the commit message?  What
about the remaining tasks listed in it?

> Dynamic linker, ld.so, is a standalone program which can be loaded at
> any address.  This patch adds a configure option, --enable-static-pie,
> to embed the part of ld.so in static executable to create static position
> independent executable (static PIE).  A static PIE is similar to static
> executable, but can be loaded at any address without help from a dynamic
> linker.  When --enable-static-pie is used to configure glibc, libc.a is
> built as PIE and all static executables, including tests, are built as
> static PIE.  The resulting libc.a can be used together with GCC 8 or
> above to build static PIE with the compiler option, -static-pie.  But
> GCC 8 isn't required to build glibc with --enable-static-pie.  When an
> older GCC is used to build glibc with --enable-static-pie, proper input
> files are passed to linker to create static executables as static PIE,
> together with "-z text" to prevent dynamic relocations in read-only
> segments, which are allowed in static PIE.

The last sentence is unclear.  Is -z text required to use a glibc
compiled by an earlier GCC?  What exactly is the problem with dynamic
relocations in read-only segments?  Are they allowed or disallowed?
Can we support .data.relro?

> Static PIE can work on all architectures which support PIE, provided:
>
> 1. Target must support accessing of local functions without dynamic
> relocations, which is needed in start.S to call __libc_start_main with
> function addresses of __libc_csu_init, __libc_csu_fini and main.

Are there really ABI concerns for the statically linked case?  It
should not be necessary to pass these function pointers.

> All functions in statice PIE are local functions.  If PIE start.S
> can't

Typo: “statice”

> 6. __brk works without TLS nor dynamic relocations in read-only section
> so that it can be used by __libc_setup_tls to initializes TLS in static
> PIE.

Note that some kernels have strange address space layouts which
prevent __brk from working reliably.


> NB: When glibc is built with GCC defaulted to PIE, libc.a is compiled
> with -fPIE, regardless if --enable-static-pie is used to configure glibc.
> When glibc is configured with --enable-static-pie, libc.a is compiled
> with -fPIE, regardless wether GCC defaults to PIE or not.  The same libc.a
> can be used to build both static executable and static PIE.  There is no
> need for separate PIE copy of libc.a.

Is there a code size cost to PIE?

> Linker requirements to build glibc with --enable-static-pie:
>
> 1. Linker supports --no-dynamic-linker to remove PT_INTERP segment from
> static PIE.
> 2. Linker can create working static PIE.  The x86-64 linker needs the
> fix for
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21782

So binutils 2.29 is the minimum requirement on x86-64?

Can an earlier binutils version be used to build a static library
which is usable for PIE with binutils 2.29+?

> +'--enable-static-pie'
> +     Build static executables, including tests, as position independent
> +     executable (static PIE) which is similar to static executable, but
> +     can be loaded at any address without help from a dynamic linker.
> +     The resulting libc.a can be used with the GCC option, -static-pie,
> +     which is available with GCC 8 or above, to create static PIE. Only
> +     i686, x86-64 and x32 targets are verified to work.

Drop the last sentence, it will be outdated soon.

> diff --git a/Makeconfig b/Makeconfig

The reason for some of the changes are not obvious at all to me, and
the ChangeLog doesn't give an explanation either.

> new file mode 100644
> index 0000000000..aa9302602b
> --- /dev/null
> +++ b/elf/dl-reloc-static-pie.c

Is there anything which inhibits compilation of this file ith the
stack protector?  I think this is necessary because
_dl_relocate_static_pie is called so early.

> +extern struct link_map * _dl_get_dl_main_map (void)
> +  __attribute__ ((visibility ("hidden")));

This should go into a header file somewhere, so that the declaration
can be checked against the definition.

> diff --git a/elf/dl-support.c b/elf/dl-support.c
> index 235d3a7f46..b9fc1a66fe 100644
> --- a/elf/dl-support.c
> +++ b/elf/dl-support.c
> @@ -385,3 +385,14 @@ _dl_non_dynamic_init (void)
>  #ifdef DL_SYSINFO_IMPLEMENTATION
>  DL_SYSINFO_IMPLEMENTATION
>  #endif
> +
> +#if ENABLE_STATIC_PIE
> +/* Since relocation to hidden _dl_main_map causes relocation overflow on
> +   aarch64, a function is used to get the address of _dl_main_map.  */
> +
> +struct link_map *
> +_dl_get_dl_main_map (void)
> +{
> +  return &_dl_main_map;
> +}
> +#endif

Is this issue really aarch64-specific, or could it affect other
targets?