public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]
@ 2017-11-01 12:46 H.J. Lu
  2017-11-01 16:04 ` Joseph Myers
  0 siblings, 1 reply; 37+ messages in thread
From: H.J. Lu @ 2017-11-01 12:46 UTC (permalink / raw)
  To: GNU C Library

I'd like to get static PIE:

https://sourceware.org/ml/libc-alpha/2017-10/msg00587.html

Static PIE is simply an extension of ld.so.  The following changes are made
for static PIE:

1. Add a new function, _dl_relocate_static_pie, to:
   a. Get the run-time load address.
   b. Read the dynamic section.
   c. Perform dynamic relocations.
Dynamic linker also performs these steps.  But static PIE doesn't load
any shared objects.
2. Call _dl_relocate_static_pie at entrance of LIBC_START_MAIN in
libc.a.  crt1.o, which is used to create dynamic and non-PIE static
executables, is updated to include a dummy _dl_relocate_static_pie.
Pcrt1.o is added to create static PIE, which will link in the real
_dl_relocate_static_pie.  gPcrt1.o is also added to create static PIE
with -pg.

The main issues with static PIE are

1. Many binutils targets don't handle PIE properly.  I opened a few binutils
bugs for PIE.
2. Many assembly codes assumes PIC == SHARED. I opened a glibc bug for it.
3. Some dl-machine.h files may not handle undefined weak symbols in PIE
properly.   But we will never know for sure unless we build static PIE.

I'd like to add static PIE support into glibc 2.27, which works on
i686 and x86-64.
I will help other target developers get static PIE working for his/her target.

-- 
H.J.

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]
@ 2017-12-15 11:58 H.J. Lu
  0 siblings, 0 replies; 37+ messages in thread
From: H.J. Lu @ 2017-12-15 11:58 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: Szabolcs Nagy, nd, Joseph Myers, GNU C Library

On Fri, Dec 8, 2017 at 5:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Dec 1, 2017 at 10:24 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Nov 30, 2017 at 1:44 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> H.J.,
>>>
>>> High Level:
>>>
>>> At a high level I have no objection with the idea of static PIE executables,
>>> it makes sense to support such things.
>>
>> Thanks for your feedbacks.
>>
>>> My only nit is that we need to do a better job of explaining to users why
>>> they would use them and under what circumstances. To that end you have a bit
>>> more work to do in the commit message, install.texit, and NEWS entry.
>>>
>>> Design:
>>>
>>> I have one design question below which around testing static non-PIE executables
>>> in a --enable-static-pie build. See below.
>>>
>>> Implementation:
>>>
>>> Everything looks good except the use of firstword in +link-static-before-libc,
>>> which I describe below. I think this is a hack and should be changed to better
>>> represent the expected semantics and structure you are looking to support.
>>
>> Fixed.
>>
>>> Thank you for your work in this area.
>>>
>>> Look forward to a v2.
>>>
>>>> From 7026a79c1f71f5decd135208503fd4186193ffb8 Mon Sep 17 00:00:00 2001
>>>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>>> Date: Mon, 17 Jul 2017 08:17:32 -0700
>>>> Subject: [PATCH] Add --enable-static-pie configure option to build static PIE
>>>>  [BZ #19574]
>>>>
>>>> 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.
>>>
>>> You write "which are allowed", shouldn't that be "which are not allowed"?
>>
>> Fixed.
>>
>>> The commit message must explain the following:
>>>
>>> * Why would a user use this feature?
>>>   - What does it provide over and beyond existing static executables
>>>
>>> * How does a user decide to use this feature?
>>>   - Should everyone use it?
>>>   - Should you use it if you care about security, and what does it cost?
>>>
>>> Please include the answers to these questions in a the next versions
>>> commit message.
>>
>> I added :
>>
>> Static PIE extends address space layout randomization to static
>> executables.  It provides additional security hardening benefits at
>> the cost of some memory and performance.
>>
>> Is this OK?
>>
>>>> @@ -420,7 +440,7 @@ endif
>>>>  # Command for statically linking programs with the C library.
>>>>  ifndef +link-static
>>>>  +link-static-before-libc = $(CC) -nostdlib -nostartfiles -static -o $@ \
>>>> -           $(DEFAULT-LDFLAGS-$(@F)) \
>>>> +           $(firstword $(DEFAULT-LDFLAGS-$(@F)) $(default-pie-ldflag)) \
>>>
>>> Is the use of firstword here just a hack to put $(no-pie-ldflag) first so
>>> you can override it with the subsequent $(default-pie-ldflag)?
>>>
>>> It is not a robust design to use firstword here because it implies that the
>>> DEFAUTL-LDFLAGS-$(@F) has some structure that we are not documenting.
>>>
>>> I would like to see this done some other way. My preference would be for a new
>>> value other than DEFAULT-LDFLAGS to control the PIE-ness of the built progarm.
>>>
>>
>> I replaced DEFAUTL-LDFLAGS-$(@F) with $($(@F)-no-pie).   Now I have
>>
>>  # Command for statically linking programs with the C library.
>>  ifndef +link-static
>>  +link-static-before-libc = $(CC) -nostdlib -nostartfiles -static -o $@ \
>> -       $(DEFAULT-LDFLAGS-$(@F)) \
>> +       $(if $($(@F)-no-pie),$(no-pie-ldflag),$(default-pie-ldflag)) \
>>         $(sysdep-LDFLAGS) $(LDFLAGS) $(LDFLAGS-$(@F))  \
>>
>>>>
>>>> diff --git a/NEWS b/NEWS
>>>> index ab14d1eb1b..61598be94d 100644
>>>> --- a/NEWS
>>>> +++ b/NEWS
>>>> @@ -9,6 +9,11 @@ Version 2.27
>>>>
>>>>  Major new features:
>>>>
>>>> +* Add --enable-static-pie configure option to build static PIE.  The
>>>> +  resulting libc.a can be used with the GCC option, -static-pie, which
>>>> +  is available with GCC 8 or above, to create static position independent
>>>> +  executable (static PIE).
>>>> +
>>>
>>> The description of a new configure option is relevant only to INSTALL.
>>>
>>> We must explain when users would use this feature and why. NEWS entries are
>>> user facing and must explain the function of the new feature. Does it improve
>>> security for static binaries? Should users switch to using them instead of
>>> normal static binaries?
>>>
>>> Lastly, we must explain which machines are supported in this initial release
>>> of the feature. Only x86_64? You need not check all machines, other maintainers
>>> can check and adjust the NEWS entry, but we have to commit to at least one
>>> machine supporting this feature, which I assume is x86_64.
>>>
>>> For example:
>>>
>>> * The GNU C Library can now be compiled with support for building static
>>>   PIE executables (See --enable-static-pie in INSTALL). These static PIE
>>>   exectuables are like static executables but can be loaded at any address
>>>   and provide additional security hardening benefits at the cost of some
>>>   memory and performance. When the library is built with --enable-static-pie
>>>   the resulting libc.a is usable with GCC 8 and above to create static PIE
>>>   executables using the GCC option '-static-pie'. This feature is currently
>>>   supported on x86_64.
>>>
>>
>> I took your example.  Thanks.
>>
>>>
>>>> diff --git a/configure.ac b/configure.ac
>>>> index 8ebc490a55..ae219f8fe0 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -176,6 +176,11 @@ AC_ARG_ENABLE([profile],
>>>>                            [build profiled library @<:@default=no@:>@]),
>>>>             [profile=$enableval],
>>>>             [profile=no])
>>>> +AC_ARG_ENABLE([static-pie],
>>>> +           AC_HELP_STRING([--enable-static-pie],
>>>> +                          [build static executables as PIE @<:@default=no@:>@]),
>>>
>>> This does 2 things:
>>> * It enables support for building static PIE executables.
>>> * It builds all static binaries and tests in the testsuite as static PIE executables.
>>>
>>> It should say that e.g.
>>>
>>> "Enable static PIE executable support and use it in the testsuite."
>>>
>>> I understand the desire to use such a functionality to test static PIE executables
>>> by converting the entire testsuite to use them, but we still need to test non-PIE
>>> static executables? How are we still doing that after this change?
>>>
>>> How are we testing non-PIE static executables after this change?
>>
>> This is similar to PIE vs non-PIE.  When you build glibc with GCC
>> defaulting to PIE, most of dynamic tests are built as PIE, except for
>> a couple of them linked with $(no-pie-ldflag).   I added
>>
>> elf/tst-tls1-static-non-pie.c
>>
>> which is always built as  non-PIE static executable, regardless if
>> --enable-static-pie is used to configure glibc.
>>
>> To get better coverage for non-PIE, we need to build glibc with GCC
>> defaulting to non-PIE and configure glibc without --enable-static-pie.
>>
>>>> diff --git a/manual/install.texi b/manual/install.texi
>>>> index f1fa28c937..86193ade3f 100644
>>>> --- a/manual/install.texi
>>>> +++ b/manual/install.texi
>>>> @@ -120,6 +120,13 @@ Don't build shared libraries even if it is possible.  Not all systems
>>>>  support shared libraries; you need ELF support and (currently) the GNU
>>>>  linker.
>>>>
>>>> +@item --enable-static-pie
>>>
>>> This should be rewritten to explain the feature that it enables first,
>>> and then the ancilliary benefits like turning it on in the testsuite.
>>>
>>>> +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.
>>>> +
>>
>> I changed it to
>>
>> '--enable-static-pie'
>>      Enable static position independent executable (static PIE) support.
>>      Static PIE is similar to static executable, but can be loaded at
>>      any address without help from a dynamic linker.  All static
>>      programs as well as static tests are built as static PIE, except
>>      for those marked with no-pie.  The resulting glibc can be used with
>>      the GCC option, -static-pie, which is available with GCC 8 or
>>      above, to create static PIE.
>>
>> Here is the updated patch.
>>
>> Using GCC 7 and binutils master branch, build-many-glibcs.py with
>> --enable-static-pie with all patches for static PIE applied have the
>> following build successes:
>>
>> PASS: glibcs-aarch64_be-linux-gnu build
>> PASS: glibcs-aarch64-linux-gnu build
>> PASS: glibcs-armeb-linux-gnueabi-be8 build
>> PASS: glibcs-armeb-linux-gnueabi build
>> PASS: glibcs-armeb-linux-gnueabihf-be8 build
>> PASS: glibcs-armeb-linux-gnueabihf build
>> PASS: glibcs-arm-linux-gnueabi build
>> PASS: glibcs-arm-linux-gnueabihf build
>> PASS: glibcs-arm-linux-gnueabihf-v7a build
>> PASS: glibcs-arm-linux-gnueabihf-v7a-disable-multi-arch build
>> PASS: glibcs-m68k-linux-gnu build
>> PASS: glibcs-microblazeel-linux-gnu build
>> PASS: glibcs-microblaze-linux-gnu build
>> PASS: glibcs-mips64el-linux-gnu-n32 build
>> PASS: glibcs-mips64el-linux-gnu-n32-nan2008 build
>> PASS: glibcs-mips64el-linux-gnu-n32-nan2008-soft build
>> PASS: glibcs-mips64el-linux-gnu-n32-soft build
>> PASS: glibcs-mips64el-linux-gnu-n64 build
>> PASS: glibcs-mips64el-linux-gnu-n64-nan2008 build
>> PASS: glibcs-mips64el-linux-gnu-n64-nan2008-soft build
>> PASS: glibcs-mips64el-linux-gnu-n64-soft build
>> PASS: glibcs-mips64-linux-gnu-n32 build
>> PASS: glibcs-mips64-linux-gnu-n32-nan2008 build
>> PASS: glibcs-mips64-linux-gnu-n32-nan2008-soft build
>> PASS: glibcs-mips64-linux-gnu-n32-soft build
>> PASS: glibcs-mips64-linux-gnu-n64 build
>> PASS: glibcs-mips64-linux-gnu-n64-nan2008 build
>> PASS: glibcs-mips64-linux-gnu-n64-nan2008-soft build
>> PASS: glibcs-mips64-linux-gnu-n64-soft build
>> PASS: glibcs-mipsel-linux-gnu build
>> PASS: glibcs-mipsel-linux-gnu-nan2008 build
>> PASS: glibcs-mipsel-linux-gnu-nan2008-soft build
>> PASS: glibcs-mipsel-linux-gnu-soft build
>> PASS: glibcs-mips-linux-gnu build
>> PASS: glibcs-mips-linux-gnu-nan2008 build
>> PASS: glibcs-mips-linux-gnu-nan2008-soft build
>> PASS: glibcs-mips-linux-gnu-soft build
>> PASS: glibcs-nios2-linux-gnu build
>> PASS: glibcs-powerpc64le-linux-gnu build
>> PASS: glibcs-powerpc64-linux-gnu build
>> PASS: glibcs-tilegxbe-linux-gnu-32 build
>> PASS: glibcs-tilegxbe-linux-gnu build
>> PASS: glibcs-tilegx-linux-gnu-32 build
>> PASS: glibcs-tilegx-linux-gnu build
>> PASS: glibcs-tilepro-linux-gnu build
>>
>> I don't know how many of them actually work, except for aarch64.
>>
>> Thanks.
>>
>
> Hi Carlos,
>
> Do you get a chance to take a look
>
> https://sourceware.org/ml/libc-alpha/2017-12/msg00033.html
>

PING.

-- 
H.J.

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2017-12-19  1:14 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-01 12:46 PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574] H.J. Lu
2017-11-01 16:04 ` Joseph Myers
2017-11-01 16:06   ` H.J. Lu
2017-11-03 17:57     ` H.J. Lu
2017-11-19  2:40       ` H.J. Lu
2017-11-19 15:39         ` Florian Weimer
2017-11-19 16:17           ` H.J. Lu
2017-11-19 19:52             ` H.J. Lu
2017-11-20 14:17             ` Joseph Myers
2017-11-23 14:09               ` H.J. Lu
2017-11-20 12:16         ` Szabolcs Nagy
2017-11-23 13:59           ` H.J. Lu
2017-11-24 13:07             ` Szabolcs Nagy
2017-11-24 15:03               ` H.J. Lu
2017-11-24 22:24                 ` H.J. Lu
2017-11-30 14:00                   ` H.J. Lu
2017-11-30 15:28                     ` Joseph Myers
2017-11-30 16:24                       ` H.J. Lu
2017-11-30 16:37                         ` Joseph Myers
2017-11-30 16:56                           ` H.J. Lu
2017-11-30 18:45                             ` Carlos O'Donell
2017-11-30 21:45                   ` Carlos O'Donell
2017-11-30 22:37                     ` Maciej W. Rozycki
     [not found]                       ` <CAMe9rOpDRknZANuSvXAqU_qaXzGRjt=uY5BZLJoE_o9Ke+9yfw@mail.gmail.com>
     [not found]                         ` <alpine.DEB.2.00.1711302308170.31156@tp.orcam.me.uk>
2017-12-01  1:08                           ` H.J. Lu
2017-12-01  1:58                             ` Maciej W. Rozycki
2017-12-01  4:18                               ` H.J. Lu
2017-12-01  9:59                                 ` Maciej W. Rozycki
2017-12-01 12:27                                   ` Joseph Myers
2017-12-01 13:35                                     ` H.J. Lu
2017-12-01 18:24                     ` H.J. Lu
2017-12-08 13:14                       ` H.J. Lu
2017-12-15 21:19                       ` Carlos O'Donell
2017-12-16  2:04                         ` H.J. Lu
2017-12-16  3:06                           ` Carlos O'Donell
2017-12-18 13:37                           ` Joseph Myers
2017-12-19  1:14                             ` H.J. Lu
2017-12-15 11:58 H.J. Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).