New option --enable-pie-programs
Checks
| Context |
Check |
Description |
| dj/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| dj/TryBot-32bit |
success
|
Build for i686
|
Commit Message
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(-)
Comments
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
* 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
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
* 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
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
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
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?
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.
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
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
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
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
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
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.
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
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.
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
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.
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.
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.
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
@@ -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'
@@ -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.
@@ -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"
+
+
@@ -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)
@@ -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