This is the mail archive of the
mailing list for the glibc project.
Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, nd <nd at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 8 Dec 2017 05:14:34 -0800
- Subject: Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoyPf-77=cqmEW5Vg2KHwq48g6giW38qpA=oDUsnHaxCA@mail.gmail.com> <alpine.DEB.firstname.lastname@example.org> <CAMe9rOrWi1W+F6K3TRL-2ipz-K4e0aP0ywsVg0XWgdCU1FV7OQ@mail.gmail.com> <CAMe9rOrTW7-JBtfOWjQrqMtS6Kp8efsAAbouFwQOnaAzh=sNpA@mail.gmail.com> <CAMe9rOr5qR-MnP+bEY_3OPdPK1qTnn_7JLi3Xn688E9JWKr1Zw@mail.gmail.com> <5A12C781.email@example.com> <CAMe9rOohYeS4BJFp=TB4Zz26V4K2n8ZXSJX9kYqgEa=eW+w1xQ@mail.gmail.com> <5A18196C.firstname.lastname@example.org> <CAMe9rOqFfabivUDke1_ZxyEtV+L9T7VwKKdsdnR9M418L2TQBg@mail.gmail.com> <CAMe9rOpNdwd52vEnAUzOkmwkJXUWZz9-=dc9xfeZ96CYVM=8gQ@mail.gmail.com> <email@example.com> <CAMe9rOpehZgqn6AXyRf8e99eTO8_Vw2+GVgcEyie0cW3fwwefirstname.lastname@example.org>
On Fri, Dec 1, 2017 at 10:24 AM, H.J. Lu <email@example.com> wrote:
> On Thu, Nov 30, 2017 at 1:44 PM, Carlos O'Donell <firstname.lastname@example.org> wrote:
>> 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.
>> I have one design question below which around testing static non-PIE executables
>> in a --enable-static-pie build. See below.
>> 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.
>> 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" <email@example.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"?
>> 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@:>@]),
>>> + 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
> 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
>>> +@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 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.
Do you get a chance to take a look