[PATCH] New option --enable-pie-programs

[PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

Add a new option --enable-pie-programs to build tests and binaries as
PIE.  This allows building all dynamic programs in glibc (e.g.
iconvconfig, getconf, etc.) as PIE on architectures that do not have
-static-pie.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
---
 INSTALL             | 10 +++++++---
 Makeconfig          |  7 +++++++
 configure           | 17 +++++++++++++++++
 configure.ac        | 11 +++++++++++
 manual/install.texi |  9 +++++++--
 5 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/INSTALL b/INSTALL
index 02dcf6b1ca..30a071a702 100644
--- a/INSTALL
+++ b/INSTALL
@@ -111,6 +111,10 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
      systems support shared libraries; you need ELF support and
      (currently) the GNU linker.
 
+'--enable-pie-programs'
+     Build glibc programs and tests in the testsuite as position
+     independent executables (PIE).
+
 '--enable-static-pie'
      Enable static position independent executable (static PIE) support.
      Static PIE is similar to static executable, but can be loaded at
@@ -118,9 +122,9 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
      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. This option also implies that glibc
-     programs and tests are created as dynamic position independent
-     executables (PIE) by default.
+     above, to create static PIE. This option also implies
+     '--enable-pie-programs', where glibc programs and tests are created
+     as dynamic position independent executables (PIE) by default.
 
 '--enable-cet'
 '--enable-cet=permissive'
diff --git a/Makeconfig b/Makeconfig
index 3fa2f13003..1695e48ead 100644
--- a/Makeconfig
+++ b/Makeconfig
@@ -1,4 +1,5 @@
 # Copyright (C) 1991-2021 Free Software Foundation, Inc.
+# Copyright (C) The GNU Toolchain Authors.
 # This file is part of the GNU C Library.
 
 # The GNU C Library is free software; you can redistribute it and/or
@@ -390,6 +391,12 @@ default-pie-ldflag = -Wl,-pie,--no-dynamic-linker,--eh-frame-hdr,-z,text
 endif
 endif
 
+# Build glibc programs with PIE.
+ifeq (yes,$(pie-programs))
+pic-default = -DPIC
+pie-default = $(pie-ccflag)
+endif
+
 # If lazy relocations are disabled, add the -z now flag.  Use
 # LDFLAGS-lib.so instead of LDFLAGS.so, to avoid adding the flag to
 # test modules.
diff --git a/configure b/configure
index 2f9adca064..47f5536745 100755
--- a/configure
+++ b/configure
@@ -767,6 +767,7 @@ with_nonshared_cflags
 enable_sanity_checks
 enable_shared
 enable_profile
+enable_pie_programs
 enable_static_pie
 enable_timezone_tools
 enable_hardcoded_path_in_tests
@@ -1423,6 +1424,8 @@ Optional Features:
                           in special situations) [default=yes]
   --enable-shared         build shared library [default=yes if GNU ld]
   --enable-profile        build profiled library [default=no]
+  --enable-pie-programs   Build glibc programs and tests in the testsuite as
+                          PIE [default=no]
   --enable-static-pie     enable static PIE support and use it in the
                           testsuite [default=no]
   --disable-timezone-tools
@@ -3408,6 +3411,13 @@ else
   profile=no
 fi
 
+# Check whether --enable-pie-programs was given.
+if test "${enable_pie_programs+set}" = set; then :
+  enableval=$enable_pie_programs; pie_programs=$enableval
+else
+  pie_programs=no
+fi
+
 # Check whether --enable-static-pie was given.
 if test "${enable_static_pie+set}" = set; then :
   enableval=$enable_static_pie; static_pie=$enableval
@@ -7014,6 +7024,13 @@ fi
 config_vars="$config_vars
 enable-static-pie = $static_pie"
 
+if test "$pie_programs" = yes; then
+  libc_cv_pie_default=yes
+fi
+config_vars="$config_vars
+pie-programs = $pie_programs"
+
+
 
 
 
diff --git a/configure.ac b/configure.ac
index 7eb4239359..7cfbf3f825 100644
--- a/configure.ac
+++ b/configure.ac
@@ -179,6 +179,11 @@ AC_ARG_ENABLE([profile],
 			     [build profiled library @<:@default=no@:>@]),
 	      [profile=$enableval],
 	      [profile=no])
+AC_ARG_ENABLE([pie-programs],
+	      AS_HELP_STRING([--enable-pie-programs],
+			     [Build glibc programs and tests in the testsuite as PIE @<:@default=no@:>@]),
+	      [pie_programs=$enableval],
+	      [pie_programs=no])
 AC_ARG_ENABLE([static-pie],
 	      AS_HELP_STRING([--enable-static-pie],
 			     [enable static PIE support and use it in the testsuite @<:@default=no@:>@]),
@@ -1876,6 +1881,12 @@ if test "$static_pie" = yes; then
 fi
 LIBC_CONFIG_VAR([enable-static-pie], [$static_pie])
 
+if test "$pie_programs" = yes; then
+  libc_cv_pie_default=yes
+fi
+LIBC_CONFIG_VAR([pie-programs], [$pie_programs])
+
+
 AC_SUBST(profile)
 AC_SUBST(static_nss)
 
diff --git a/manual/install.texi b/manual/install.texi
index 46f73b538d..9f7acfe9cd 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -141,6 +141,10 @@ 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-pie-programs
+Build glibc programs and tests in the testsuite as position independent
+executables (PIE).
+
 @item --enable-static-pie
 Enable static position independent executable (static PIE) support.
 Static PIE is similar to static executable, but can be loaded at any
@@ -148,8 +152,9 @@ 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.  This option also implies that glibc programs and tests are created
-as dynamic position independent executables (PIE) by default.
+PIE.  This option also implies @option{--enable-pie-programs}, where glibc
+programs and tests are created as dynamic position independent executables
+(PIE) by default.
 
 @item --enable-cet
 @itemx --enable-cet=permissive
-- 
2.31.1

Re: [PATCH] New option --enable-pie-programs

[Florian Weimer]

* Siddhesh Poyarekar:

> Add a new option --enable-pie-programs to build tests and binaries as
> PIE.  This allows building all dynamic programs in glibc (e.g.
> iconvconfig, getconf, etc.) as PIE on architectures that do not have
> -static-pie.

Please integrate this in some way with libc_cv_cc_pie_default and
libc_cv_pie_default.  Probably --enable-pie-programs should default to
yes if the toolchain defauls to PIE.

Thanks,
Florian

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/16/21 19:28, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> Add a new option --enable-pie-programs to build tests and binaries as
>> PIE.  This allows building all dynamic programs in glibc (e.g.
>> iconvconfig, getconf, etc.) as PIE on architectures that do not have
>> -static-pie.
> 
> Please integrate this in some way with libc_cv_cc_pie_default and
> libc_cv_pie_default.  Probably --enable-pie-programs should default to
> yes if the toolchain defauls to PIE.

AFAICT, libc_cv_cc_pie_default is only to set -fno-pie for non-PIE 
linking with a toolchain that defaults to pie.  PIE linking otherwise is 
controlled accross the board with libc_cv_pie_default, which includes 
build-pie-default, static-pie and now pie-programs.

So I reckon it is integrated; the new pie-programs variable is only to 
set CFLAGS to -fPIC.

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[Florian Weimer]

* Siddhesh Poyarekar:

> On 11/16/21 19:28, Florian Weimer wrote:
>> * Siddhesh Poyarekar:
>> 
>>> Add a new option --enable-pie-programs to build tests and binaries as
>>> PIE.  This allows building all dynamic programs in glibc (e.g.
>>> iconvconfig, getconf, etc.) as PIE on architectures that do not have
>>> -static-pie.
>> Please integrate this in some way with libc_cv_cc_pie_default and
>> libc_cv_pie_default.  Probably --enable-pie-programs should default to
>> yes if the toolchain defauls to PIE.
>
> AFAICT, libc_cv_cc_pie_default is only to set -fno-pie for non-PIE
> linking with a toolchain that defaults to pie.  PIE linking otherwise
> is controlled accross the board with libc_cv_pie_default, which
> includes build-pie-default, static-pie and now pie-programs.
>
> So I reckon it is integrated; the new pie-programs variable is only to
> set CFLAGS to -fPIC.

--enable-pie-programs=no with a default-PIE toolchain still produces PIE
programs, right?

Thanks,
Florian

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/17/21 14:09, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> On 11/16/21 19:28, Florian Weimer wrote:
>>> * Siddhesh Poyarekar:
>>>
>>>> Add a new option --enable-pie-programs to build tests and binaries as
>>>> PIE.  This allows building all dynamic programs in glibc (e.g.
>>>> iconvconfig, getconf, etc.) as PIE on architectures that do not have
>>>> -static-pie.
>>> Please integrate this in some way with libc_cv_cc_pie_default and
>>> libc_cv_pie_default.  Probably --enable-pie-programs should default to
>>> yes if the toolchain defauls to PIE.
>>
>> AFAICT, libc_cv_cc_pie_default is only to set -fno-pie for non-PIE
>> linking with a toolchain that defaults to pie.  PIE linking otherwise
>> is controlled accross the board with libc_cv_pie_default, which
>> includes build-pie-default, static-pie and now pie-programs.
>>
>> So I reckon it is integrated; the new pie-programs variable is only to
>> set CFLAGS to -fPIC.
> 
> --enable-pie-programs=no with a default-PIE toolchain still produces PIE
> programs, right?

Yes, it should.  $libc_cv_pie_default is overwritten only in case of 
--enable-pie-programs=yes, otherwise it is left alone, much like 
--enable-static-pie.

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[Florian Weimer]

* Siddhesh Poyarekar:

> On 11/17/21 14:09, Florian Weimer wrote:
>> * Siddhesh Poyarekar:
>> 
>>> On 11/16/21 19:28, Florian Weimer wrote:
>>>> * Siddhesh Poyarekar:
>>>>
>>>>> Add a new option --enable-pie-programs to build tests and binaries as
>>>>> PIE.  This allows building all dynamic programs in glibc (e.g.
>>>>> iconvconfig, getconf, etc.) as PIE on architectures that do not have
>>>>> -static-pie.
>>>> Please integrate this in some way with libc_cv_cc_pie_default and
>>>> libc_cv_pie_default.  Probably --enable-pie-programs should default to
>>>> yes if the toolchain defauls to PIE.
>>>
>>> AFAICT, libc_cv_cc_pie_default is only to set -fno-pie for non-PIE
>>> linking with a toolchain that defaults to pie.  PIE linking otherwise
>>> is controlled accross the board with libc_cv_pie_default, which
>>> includes build-pie-default, static-pie and now pie-programs.
>>>
>>> So I reckon it is integrated; the new pie-programs variable is only to
>>> set CFLAGS to -fPIC.
>> --enable-pie-programs=no with a default-PIE toolchain still produces
>> PIE
>> programs, right?
>
> Yes, it should.  $libc_cv_pie_default is overwritten only in case of
> --enable-pie-programs=yes, otherwise it is left alone, much like 
> --enable-static-pie.

But that doesn't make sense, does it?  If the user requests non-PIE
programs, they should get that.

Thanks,
Florian

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/17/21 14:40, Florian Weimer wrote:
>> Yes, it should.  $libc_cv_pie_default is overwritten only in case of
>> --enable-pie-programs=yes, otherwise it is left alone, much like
>> --enable-static-pie.
> 
> But that doesn't make sense, does it?  If the user requests non-PIE
> programs, they should get that.

I suppose you're right.  That is current behaviour with 
--enable-static-pie too; wouldn't a similar argument hold for 
--enable-static-pie=no?  Or is the rationale in that case is that 
*static-pie* is disabled, not pie itself and hence the default PIE 
toolchain could get away with building PIE dynamic programs, just not 
static ones?

I wonder if the clearer option is to have a new
--enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on 
default-PIE toolchains), "dynamic" enables PIE for dynamic programs and 
"full" or "yes" enables static-pie on architectures that support it, 
terminating with an error if it's not supported.  --enable-static-pie=no 
could then imply --enable-pie=dynamic and could be deprecated.  I don't 
remember if we have ever deprecated configure flags before.

Even simpler, we could have just a yes/no option and enable static-pie 
transparently on architectures that support it, making an explicit 
--enable-static-pie=no equivalent to disabling all PIE.  It may in 
theory break a use case but I don't know if there's actually a use case 
where one would strictly want only dynamic PIE and not static PIE.

What do you think?

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote:
> I suppose you're right.  That is current behaviour with 
> --enable-static-pie too; wouldn't a similar argument hold for 
> --enable-static-pie=no?  Or is the rationale in that case is that 
> *static-pie* is disabled, not pie itself and hence the default PIE 
> toolchain could get away with building PIE dynamic programs, just not 
> static ones?
> 
> I wonder if the clearer option is to have a new
> --enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on 
> default-PIE toolchains), "dynamic" enables PIE for dynamic programs and 
> "full" or "yes" enables static-pie on architectures that support it, 
> terminating with an error if it's not supported.  --enable-static-pie=no 
> could then imply --enable-pie=dynamic and could be deprecated.  I don't 
> remember if we have ever deprecated configure flags before.
> 
> Even simpler, we could have just a yes/no option and enable static-pie 
> transparently on architectures that support it, making an explicit 
> --enable-static-pie=no equivalent to disabling all PIE.  It may in 
> theory break a use case but I don't know if there's actually a use case 
> where one would strictly want only dynamic PIE and not static PIE.

A third option (as we discussed offlist yesterday) could be to always 
build glibc dynamic programs as PIE as long as the toolchain supports 
it.  Would non-distribution use cases be adversely affected by not 
having an option to produce non-PIE glibc programs, e.g. iconvconfig, 
getconf, etc.?

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[H.J. Lu]

On Thu, Nov 18, 2021 at 1:24 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote:
> > I suppose you're right.  That is current behaviour with
> > --enable-static-pie too; wouldn't a similar argument hold for
> > --enable-static-pie=no?  Or is the rationale in that case is that
> > *static-pie* is disabled, not pie itself and hence the default PIE
> > toolchain could get away with building PIE dynamic programs, just not
> > static ones?
> >
> > I wonder if the clearer option is to have a new
> > --enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on
> > default-PIE toolchains), "dynamic" enables PIE for dynamic programs and
> > "full" or "yes" enables static-pie on architectures that support it,
> > terminating with an error if it's not supported.  --enable-static-pie=no
> > could then imply --enable-pie=dynamic and could be deprecated.  I don't
> > remember if we have ever deprecated configure flags before.
> >
> > Even simpler, we could have just a yes/no option and enable static-pie
> > transparently on architectures that support it, making an explicit
> > --enable-static-pie=no equivalent to disabling all PIE.  It may in
> > theory break a use case but I don't know if there's actually a use case
> > where one would strictly want only dynamic PIE and not static PIE.
>
> A third option (as we discussed offlist yesterday) could be to always
> build glibc dynamic programs as PIE as long as the toolchain supports
> it.  Would non-distribution use cases be adversely affected by not
> having an option to produce non-PIE glibc programs, e.g. iconvconfig,
> getconf, etc.?

How about --enable-default-pie?

-- 
H.J.

Re: [PATCH] New option --enable-pie-programs

[Adhemerval Zanella]

On 18/11/2021 09:42, H.J. Lu via Libc-alpha wrote:
> On Thu, Nov 18, 2021 at 1:24 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote:
>>> I suppose you're right.  That is current behaviour with
>>> --enable-static-pie too; wouldn't a similar argument hold for
>>> --enable-static-pie=no?  Or is the rationale in that case is that
>>> *static-pie* is disabled, not pie itself and hence the default PIE
>>> toolchain could get away with building PIE dynamic programs, just not
>>> static ones?
>>>
>>> I wonder if the clearer option is to have a new
>>> --enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on
>>> default-PIE toolchains), "dynamic" enables PIE for dynamic programs and
>>> "full" or "yes" enables static-pie on architectures that support it,
>>> terminating with an error if it's not supported.  --enable-static-pie=no
>>> could then imply --enable-pie=dynamic and could be deprecated.  I don't
>>> remember if we have ever deprecated configure flags before.
>>>
>>> Even simpler, we could have just a yes/no option and enable static-pie
>>> transparently on architectures that support it, making an explicit
>>> --enable-static-pie=no equivalent to disabling all PIE.  It may in
>>> theory break a use case but I don't know if there's actually a use case
>>> where one would strictly want only dynamic PIE and not static PIE.
>>
>> A third option (as we discussed offlist yesterday) could be to always
>> build glibc dynamic programs as PIE as long as the toolchain supports
>> it.  Would non-distribution use cases be adversely affected by not
>> having an option to produce non-PIE glibc programs, e.g. iconvconfig,
>> getconf, etc.?
> 
> How about --enable-default-pie?

Another option would be to --enable-pie=<no,auto> where 'no' disables PIE
for both both static and dynamic installed programs and 'auto' checks
compiler support and enables for everything.  I would like to provide less
options which results in less permutations to test.

 

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/18/21 18:19, Adhemerval Zanella wrote:
> 
> 
> On 18/11/2021 09:42, H.J. Lu via Libc-alpha wrote:
>> On Thu, Nov 18, 2021 at 1:24 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>>
>>> On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote:
>>>> I suppose you're right.  That is current behaviour with
>>>> --enable-static-pie too; wouldn't a similar argument hold for
>>>> --enable-static-pie=no?  Or is the rationale in that case is that
>>>> *static-pie* is disabled, not pie itself and hence the default PIE
>>>> toolchain could get away with building PIE dynamic programs, just not
>>>> static ones?
>>>>
>>>> I wonder if the clearer option is to have a new
>>>> --enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on
>>>> default-PIE toolchains), "dynamic" enables PIE for dynamic programs and
>>>> "full" or "yes" enables static-pie on architectures that support it,
>>>> terminating with an error if it's not supported.  --enable-static-pie=no
>>>> could then imply --enable-pie=dynamic and could be deprecated.  I don't
>>>> remember if we have ever deprecated configure flags before.
>>>>
>>>> Even simpler, we could have just a yes/no option and enable static-pie
>>>> transparently on architectures that support it, making an explicit
>>>> --enable-static-pie=no equivalent to disabling all PIE.  It may in
>>>> theory break a use case but I don't know if there's actually a use case
>>>> where one would strictly want only dynamic PIE and not static PIE.
>>>
>>> A third option (as we discussed offlist yesterday) could be to always
>>> build glibc dynamic programs as PIE as long as the toolchain supports
>>> it.  Would non-distribution use cases be adversely affected by not
>>> having an option to produce non-PIE glibc programs, e.g. iconvconfig,
>>> getconf, etc.?
>>
>> How about --enable-default-pie?

HJ, could you describe how you'd expect it to behave?  Would it map to 
any of the options I describe above?

> Another option would be to --enable-pie=<no,auto> where 'no' disables PIE
> for both both static and dynamic installed programs and 'auto' checks
> compiler support and enables for everything.  I would like to provide less
> options which results in less permutations to test.

OK, that sounds like the two option alternative I described above.

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[H.J. Lu]

On Thu, Nov 18, 2021 at 5:26 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 11/18/21 18:19, Adhemerval Zanella wrote:
> >
> >
> > On 18/11/2021 09:42, H.J. Lu via Libc-alpha wrote:
> >> On Thu, Nov 18, 2021 at 1:24 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> >>>
> >>> On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote:
> >>>> I suppose you're right.  That is current behaviour with
> >>>> --enable-static-pie too; wouldn't a similar argument hold for
> >>>> --enable-static-pie=no?  Or is the rationale in that case is that
> >>>> *static-pie* is disabled, not pie itself and hence the default PIE
> >>>> toolchain could get away with building PIE dynamic programs, just not
> >>>> static ones?
> >>>>
> >>>> I wonder if the clearer option is to have a new
> >>>> --enable-pie=<no|dynamic|yes/full>, where "no" disables PIE (even on
> >>>> default-PIE toolchains), "dynamic" enables PIE for dynamic programs and
> >>>> "full" or "yes" enables static-pie on architectures that support it,
> >>>> terminating with an error if it's not supported.  --enable-static-pie=no
> >>>> could then imply --enable-pie=dynamic and could be deprecated.  I don't
> >>>> remember if we have ever deprecated configure flags before.
> >>>>
> >>>> Even simpler, we could have just a yes/no option and enable static-pie
> >>>> transparently on architectures that support it, making an explicit
> >>>> --enable-static-pie=no equivalent to disabling all PIE.  It may in
> >>>> theory break a use case but I don't know if there's actually a use case
> >>>> where one would strictly want only dynamic PIE and not static PIE.
> >>>
> >>> A third option (as we discussed offlist yesterday) could be to always
> >>> build glibc dynamic programs as PIE as long as the toolchain supports
> >>> it.  Would non-distribution use cases be adversely affected by not
> >>> having an option to produce non-PIE glibc programs, e.g. iconvconfig,
> >>> getconf, etc.?
> >>
> >> How about --enable-default-pie?
>
> HJ, could you describe how you'd expect it to behave?  Would it map to
> any of the options I describe above?

--enable-default-pie builds all dynamic programs, including tests, as PIE.   If
compiler/target supports static PIE, it also builds static programs as PIE.

> > Another option would be to --enable-pie=<no,auto> where 'no' disables PIE
> > for both both static and dynamic installed programs and 'auto' checks
> > compiler support and enables for everything.  I would like to provide less
> > options which results in less permutations to test.
>
> OK, that sounds like the two option alternative I described above.
>
> Siddhesh



-- 
H.J.

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/18/21 19:11, H.J. Lu wrote:
>> HJ, could you describe how you'd expect it to behave?  Would it map to
>> any of the options I describe above?
> 
> --enable-default-pie builds all dynamic programs, including tests, as PIE.   If
> compiler/target supports static PIE, it also builds static programs as PIE.

OK I guess there's close to consensus on a single flag that enables 
dynamic PIE and if supported by the target, transparently enable 
static-pie as well.  So next question: is it OK to enable by default and 
require users to specify --enable-pie=no to disable PIE?

Also, would you be OK with calling it --enable-pie HJ?  Or do you feel 
strongly about calling it --enable-default-pie?  Same question for 
Adhemerval; I am OK with calling it --enable-cake fwiw ;)

Thanks,
Siddhesh

Re: [PATCH] New option --enable-pie-programs

[H.J. Lu]

On Thu, Nov 18, 2021 at 8:37 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 11/18/21 19:11, H.J. Lu wrote:
> >> HJ, could you describe how you'd expect it to behave?  Would it map to
> >> any of the options I describe above?
> >
> > --enable-default-pie builds all dynamic programs, including tests, as PIE.   If
> > compiler/target supports static PIE, it also builds static programs as PIE.
>
> OK I guess there's close to consensus on a single flag that enables
> dynamic PIE and if supported by the target, transparently enable
> static-pie as well.  So next question: is it OK to enable by default and
> require users to specify --enable-pie=no to disable PIE?
>
> Also, would you be OK with calling it --enable-pie HJ?  Or do you feel

--enable-pie means --disable-pie which looks odd since PIE isn't really
disabled, just isn't the default.   But I don't feel it very strongly.   As for
the default, I believe it should be NO to avoid any surprises.

> strongly about calling it --enable-default-pie?  Same question for
> Adhemerval; I am OK with calling it --enable-cake fwiw ;)
>
> Thanks,
> Siddhesh



-- 
H.J.

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/18/21 22:14, H.J. Lu wrote:
> --enable-pie means --disable-pie which looks odd since PIE isn't really
> disabled, just isn't the default.   But I don't feel it very strongly.   As for

Ahh then the option you suggested is actually different, in that 
--enable-default-pie=no doesn't actually disable PIE for default-PIE 
toolchains.  That is, it is similar to the --enable-pie-programs option 
I implemented with the added functionality of transparently enabling 
static-pie.  Have I understood that correctly?

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[H.J. Lu]

On Thu, Nov 18, 2021 at 8:49 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 11/18/21 22:14, H.J. Lu wrote:
> > --enable-pie means --disable-pie which looks odd since PIE isn't really
> > disabled, just isn't the default.   But I don't feel it very strongly.   As for
>
> Ahh then the option you suggested is actually different, in that
> --enable-default-pie=no doesn't actually disable PIE for default-PIE
> toolchains.  That is, it is similar to the --enable-pie-programs option
> I implemented with the added functionality of transparently enabling
> static-pie.  Have I understood that correctly?
>

I am not sure.  --enable-default-pie and --disable-default-pie should
be independent of compilers, except for static PIE.  If compiler supports
static PIE, --enable-default-pie implies --enable-static-pie.

-- 
H.J.

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/18/21 22:26, H.J. Lu wrote:
> On Thu, Nov 18, 2021 at 8:49 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 11/18/21 22:14, H.J. Lu wrote:
>>> --enable-pie means --disable-pie which looks odd since PIE isn't really
>>> disabled, just isn't the default.   But I don't feel it very strongly.   As for
>>
>> Ahh then the option you suggested is actually different, in that
>> --enable-default-pie=no doesn't actually disable PIE for default-PIE
>> toolchains.  That is, it is similar to the --enable-pie-programs option
>> I implemented with the added functionality of transparently enabling
>> static-pie.  Have I understood that correctly?
>>
> 
> I am not sure.  --enable-default-pie and --disable-default-pie should
> be independent of compilers, except for static PIE.  If compiler supports
> static PIE, --enable-default-pie implies --enable-static-pie.
> 

How do you see --disable-default-pie behaving with a compiler that 
produces PIE by default?  That is, in case where 
libc_cv_cc_default_pie=yes?  Should it add -fno-pie or leave it as is?

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[H.J. Lu]

On Thu, Nov 18, 2021 at 9:54 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 11/18/21 22:26, H.J. Lu wrote:
> > On Thu, Nov 18, 2021 at 8:49 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> >>
> >> On 11/18/21 22:14, H.J. Lu wrote:
> >>> --enable-pie means --disable-pie which looks odd since PIE isn't really
> >>> disabled, just isn't the default.   But I don't feel it very strongly.   As for
> >>
> >> Ahh then the option you suggested is actually different, in that
> >> --enable-default-pie=no doesn't actually disable PIE for default-PIE
> >> toolchains.  That is, it is similar to the --enable-pie-programs option
> >> I implemented with the added functionality of transparently enabling
> >> static-pie.  Have I understood that correctly?
> >>
> >
> > I am not sure.  --enable-default-pie and --disable-default-pie should
> > be independent of compilers, except for static PIE.  If compiler supports
> > static PIE, --enable-default-pie implies --enable-static-pie.
> >
>
> How do you see --disable-default-pie behaving with a compiler that
> produces PIE by default?  That is, in case where
> libc_cv_cc_default_pie=yes?  Should it add -fno-pie or leave it as is?
>

It should add -fno-pie by default when building programs.

-- 
H.J.

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/18/21 23:28, H.J. Lu wrote:
>> How do you see --disable-default-pie behaving with a compiler that
>> produces PIE by default?  That is, in case where
>> libc_cv_cc_default_pie=yes?  Should it add -fno-pie or leave it as is?
>>
> 
> It should add -fno-pie by default when building programs.
> 

In that case I'm inclined towards --enable-default-pie=yes being the new 
default since AFAIK at least Ubuntu will have to start adding 
--enable-default-pie to its flags to maintain its current state with its 
default-pie toolchain.  With Fedora too I think we'd prefer to build PIE 
by default and I suspect other distros would be OK with that too.

Those that don't could add --disable-default-pie to continue maintaining 
status quo.  This is a step forward security-wise IMO.

Siddhesh

Re: [PATCH] New option --enable-pie-programs

[H.J. Lu]

On Thu, Nov 18, 2021 at 10:09 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 11/18/21 23:28, H.J. Lu wrote:
> >> How do you see --disable-default-pie behaving with a compiler that
> >> produces PIE by default?  That is, in case where
> >> libc_cv_cc_default_pie=yes?  Should it add -fno-pie or leave it as is?
> >>
> >
> > It should add -fno-pie by default when building programs.
> >
>
> In that case I'm inclined towards --enable-default-pie=yes being the new
> default since AFAIK at least Ubuntu will have to start adding
> --enable-default-pie to its flags to maintain its current state with its
> default-pie toolchain.  With Fedora too I think we'd prefer to build PIE
> by default and I suspect other distros would be OK with that too.
>
> Those that don't could add --disable-default-pie to continue maintaining
> status quo.  This is a step forward security-wise IMO.
>

Sounds reasonable to me.

-- 
H.J.

Re: [PATCH] New option --enable-pie-programs

[Fangrui Song]

On 2021-11-18, H.J. Lu via Libc-alpha wrote:
>On Thu, Nov 18, 2021 at 10:09 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 11/18/21 23:28, H.J. Lu wrote:
>> >> How do you see --disable-default-pie behaving with a compiler that
>> >> produces PIE by default?  That is, in case where
>> >> libc_cv_cc_default_pie=yes?  Should it add -fno-pie or leave it as is?
>> >>
>> >
>> > It should add -fno-pie by default when building programs.
>> >
>>
>> In that case I'm inclined towards --enable-default-pie=yes being the new
>> default since AFAIK at least Ubuntu will have to start adding
>> --enable-default-pie to its flags to maintain its current state with its
>> default-pie toolchain.  With Fedora too I think we'd prefer to build PIE
>> by default and I suspect other distros would be OK with that too.
>>
>> Those that don't could add --disable-default-pie to continue maintaining
>> status quo.  This is a step forward security-wise IMO.
>>
>
>Sounds reasonable to me.

As a bonus, --enable-default-pie matches the GCC configure option name:)

As of the auto mode which adds neither -fno-pic nor -fpie, I think it is
unnecessary. --enable-default-pie + --disable-default-pie are sufficient.

---

I think --enable-default-pie is the majority in the Linux world, so
perhaps someone may want to make it the default in the upstream GCC.

After one or two llvm-project releases, I'll adjust my Clang patch
https://reviews.llvm.org/D113372 to default to PIE.

Re: [PATCH] New option --enable-pie-programs

[Fāng-ruì Sòng]

On Mon, Nov 22, 2021 at 3:40 PM Fangrui Song <maskray@google.com> wrote:
>
> On 2021-11-18, H.J. Lu via Libc-alpha wrote:
> >On Thu, Nov 18, 2021 at 10:09 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> >>
> >> On 11/18/21 23:28, H.J. Lu wrote:
> >> >> How do you see --disable-default-pie behaving with a compiler that
> >> >> produces PIE by default?  That is, in case where
> >> >> libc_cv_cc_default_pie=yes?  Should it add -fno-pie or leave it as is?
> >> >>
> >> >
> >> > It should add -fno-pie by default when building programs.
> >> >
> >>
> >> In that case I'm inclined towards --enable-default-pie=yes being the new
> >> default since AFAIK at least Ubuntu will have to start adding
> >> --enable-default-pie to its flags to maintain its current state with its
> >> default-pie toolchain.  With Fedora too I think we'd prefer to build PIE
> >> by default and I suspect other distros would be OK with that too.
> >>
> >> Those that don't could add --disable-default-pie to continue maintaining
> >> status quo.  This is a step forward security-wise IMO.
> >>
> >
> >Sounds reasonable to me.
>
> As a bonus, --enable-default-pie matches the GCC configure option name:)
>
> As of the auto mode which adds neither -fno-pic nor -fpie, I think it is
> unnecessary. --enable-default-pie + --disable-default-pie are sufficient.
>
> ---
>
> I think --enable-default-pie is the majority in the Linux world, so
> perhaps someone may want to make it the default in the upstream GCC.

I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398
("configure: Enable --enable-default-pie by default for Linux"), but
it has been closed.
Anyone might want to chime in?

> After one or two llvm-project releases, I'll adjust my Clang patch
> https://reviews.llvm.org/D113372 to default to PIE.

Re: [PATCH] New option --enable-pie-programs

[Siddhesh Poyarekar]

On 11/24/21 06:34, Fāng-ruì Sòng wrote:
>> I think --enable-default-pie is the majority in the Linux world, so
>> perhaps someone may want to make it the default in the upstream GCC.
> 
> I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398
> ("configure: Enable --enable-default-pie by default for Linux"), but
> it has been closed.
> Anyone might want to chime in?

gcc's use cases are much broader than that of glibc, so I'm not entirely 
sure if switching defaults for PIE would make sense.  It could be 
something to think about though once stage 1 reopens next year.

Siddhesh