Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi All,

2016-05-28 23:16 GMT+02:00 Bálint Réczey :
> Hi,
>
> 2016-05-18 2:21 GMT+02:00 Guillem Jover :
>> On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
>>> I'm not a fan myself for turning on hardening flags in the compiler itself,
>>> but if you do that, then dpkg issues like https://bugs.debian.org/823869
>>> need to be addressed (whether all obscure build systems picking these up, or
>>> not).
>>
>> That bug report is not relevant in its current form, as explained
>> there.
>>
>> If the default changes in the Debian default compiler, then I'll just
>> make the +pie option a no-op and change -pie to set -fno-PIE, so that
>> the options are only added when they are expected.
>>
>> The difference with that request is that it would currently add
>> -fno-PIE for most packages that do not change the default flags,
>> which might break their build-systems.
>
> Thank you Guilllem.
>
> Matthias, are you OK with the resolution of #823869 and would you be
> OK with using --enable-default-pie for GCC if dpkg adopts the solution
> described above?

For the record I have opened #835146, #835148 and #835149 against dpkg
and gcc-6 with a set of proposed patches [2] which seem to work well.

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:
>> I agree that it would be the easier way and I also tried building
>> packages with patched GCC 5 setting PIE as default with success,
>> but we have a CTTE decision which says that we should set
>> hardening flags through dpkg:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Guillem> Meh, I'm not going to bother reading that bug report, but
Guillem> if that's what the decision really says, then that decision
Guillem> is just bogus…

So, first, the TC didn't actually make a formal decision.  The gcc
maintainer didn't like changing the compiler defaults; dpkg-buildflags
had gotten enough traction that it seemed to be a sufficient solution,
so the bug was closed with a specific note that any interested party
could reopen.

However, I think there are several factors that are different in this
situation:

* A big concern was introducing new warnings in environments where
  -Werror was in use.  That is something we sadly have a fair bit of
  experience fixing (-Wuninitialized springs to mind) since the time of
  that bug, and that seems not to apply to PIE

* More concerns about cases where the behavior would be wrong than seem
  to apply here.

Regardless of where you make the change you'll break some packages.
That happens though; both gcc and dpkg-dev have gotten more strict abouv
various behaviors in ways that break packages within recent memory.

So, I think there's some good reading in the TC bug about the proes and
cons of various approaches, but not all of it applies, and there is a
bit of flame to wade through mixed in with some generally well-thought
discussion.
That bug definitely should not be considered binding in general, but
definitely not in this environment.

--Sam

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi,

2016-05-18 2:21 GMT+02:00 Guillem Jover :
> On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
>> I'm not a fan myself for turning on hardening flags in the compiler itself,
>> but if you do that, then dpkg issues like https://bugs.debian.org/823869
>> need to be addressed (whether all obscure build systems picking these up, or
>> not).
>
> That bug report is not relevant in its current form, as explained
> there.
>
> If the default changes in the Debian default compiler, then I'll just
> make the +pie option a no-op and change -pie to set -fno-PIE, so that
> the options are only added when they are expected.
>
> The difference with that request is that it would currently add
> -fno-PIE for most packages that do not change the default flags,
> which might break their build-systems.

Thank you Guilllem.

Matthias, are you OK with the resolution of #823869 and would you be
OK with using --enable-default-pie for GCC if dpkg adopts the solution
described above?

Cheers,
Balint

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Guillem Jover]

On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
> I'm not a fan myself for turning on hardening flags in the compiler itself,
> but if you do that, then dpkg issues like https://bugs.debian.org/823869
> need to be addressed (whether all obscure build systems picking these up, or
> not).

That bug report is not relevant in its current form, as explained
there.

If the default changes in the Debian default compiler, then I'll just
make the +pie option a no-op and change -pie to set -fno-PIE, so that
the options are only added when they are expected.

The difference with that request is that it would currently add
-fno-PIE for most packages that do not change the default flags,
which might break their build-systems.

Thanks,
Guillem

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Guillem Jover]

Hi!

On Sun, 2016-05-15 at 21:45:55 +0200, Bálint Réczey wrote:
> 2016-05-15 20:49 GMT+02:00 Niels Thykier :
> > Bálint Réczey:
> >> I think making PIE and bindnow default in dpkg (at least for amd64) would 
> >> be
> >> perfect release goals for Stretch.
> >
> > I support the end goal, but I suspect we should enable PIE by default
> > via GCC-6's new configure switch[1].  Assuming it does what I hope, then
> > it will work better than enabling PIE via dpkg-buildflags.
> >
> >  * The major issue with PIE by default is that it is not compatible
> >with -fPIC (and presumably also -static), which causes FTBFS or
> >broken ELF binaries.
> >
> >  * Assuming the GCC option does what I hope, then it would automatically
> >disable PIE for irrelevant outputs.
> >
> > My assumption seems to be aligned with the approach taking by Ubuntu.

Right, I've been pondering about the same. And I also have to agree
enabling PIE globally via dpkg-buildflags is not the right approach,
and I'm not planning to enable that in dpkg for any normal arch.
Because it would require hunting down all broken packages, and making
them opt-out from using PIE, or making them opt-out from PIE in some
parts of their build-system. It would also require a flag-day.

For bindnow, the usual process from the dpkg FAQ would still apply.

> I agree that it would be the easier way and I also tried building packages 
> with
> patched GCC 5 setting PIE as default with success, but we have a CTTE
> decision which says that we should set hardening flags through dpkg:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Meh, I'm not going to bother reading that bug report, but if that's
what the decision really says, then that decision is just bogus…

Thanks,
Guillem

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Matthias Klose]

On 15.05.2016 23:10, Iustin Pop wrote:

On 2016-05-15 21:45:55, Bálint Réczey wrote:

Hi Niels,

2016-05-15 20:49 GMT+02:00 Niels Thykier :

Bálint Réczey:

Hi,

[...]



Hi,


I think making PIE and bindnow default in dpkg (at least for amd64) would be
perfect release goals for Stretch.



I support the end goal, but I suspect we should enable PIE by default
via GCC-6's new configure switch[1].  Assuming it does what I hope, then
it will work better than enabling PIE via dpkg-buildflags.

  * The major issue with PIE by default is that it is not compatible
with -fPIC (and presumably also -static), which causes FTBFS or
broken ELF binaries.

  * Assuming the GCC option does what I hope, then it would automatically
disable PIE for irrelevant outputs.

My assumption seems to be aligned with the approach taking by Ubuntu.


I agree that it would be the easier way and I also tried building packages with
patched GCC 5 setting PIE as default with success, but we have a CTTE
decision which says that we should set hardening flags through dpkg:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688


I'm not familiar with the history of that bug (272 updates!), so excuse
my question, but:

- that bug seems to have been opened in the context of custom patches to
   GCC, back in 2009-2012
- the CTTE seems to have made an informal decision (see last update
   #272) on that topic

Would it make sense to re-evaluate that decision in the context of 2016,
i.e. (if I understand correctly) no patching of GCC 6 needed? Just a
quick ask to the CTTE asking if the decision is still valid given
today's situation.


indeed, this patch is now upstream, but still not that much used. Just 
discovered that it is not covering all front ends,
see https://gcc.gnu.org/PR71072 for an example.  I'm happy to see that the 
reproducible build maintainers took the issue of setting c/c++ timestamp values 
upstream, and encourage to do the same for any other default flags setting.


I'm not a fan myself for turning on hardening flags in the compiler itself, but 
if you do that, then dpkg issues like https://bugs.debian.org/823869 need to be 
addressed (whether all obscure build systems picking these up, or not).


Matthias

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bastien Roucaries]

Le 15 mai 2016 20:49:38 GMT+02:00, Niels Thykier  a écrit :
>Bálint Réczey:
>> Hi,
>> 
>> [...]
>> 
>
>Hi,
>
>> I think making PIE and bindnow default in dpkg (at least for amd64)
>would be
>> perfect release goals for Stretch.
>> 
>
>I support the end goal, but I suspect we should enable PIE by default
>via GCC-6's new configure switch[1].  Assuming it does what I hope,
>then
>it will work better than enabling PIE via dpkg-buildflags.
>
> * The major issue with PIE by default is that it is not compatible
>   with -fPIC (and presumably also -static), which causes FTBFS or
>   broken ELF binaries.


It will also break some package like ImageMagick... Documentation how to fix  
(without reverting default) is not usuable by upstream.

So please improve documentation first.

Bastien
>
>* Assuming the GCC option does what I hope, then it would automatically
>   disable PIE for irrelevant outputs.
>
>My assumption seems to be aligned with the approach taking by Ubuntu.
>
>> This would make Debian on par with Fedora and Ubuntu in that regard.
>> 
>
>FTR, Fedora seems to have some special logic for adding PIE only to
>executables.
>
>> We briefly discussed that with Guillem in a related bug report:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42
>> 
>> I think the next step could be an archive rebuild with the changed
>defaults
>> if we would like to pursue this:
>>
>https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
>> 
>> I planned starting a discussion on debian-devel about PIE + bindnow,
>> too, after checking
>> all the packages which contain statically compiled binaries because
>> they may need patching
>> to disable PIE flags based on Lunar's post:
>> https://people.debian.org/~lunar/blog/posts/aslr_now/
>> 
>> Cheers,
>> Balint
>> 
>>>[...]
>
>In summary:
>
> * I would welcome bindnow by default via dpkg-buildflags.
>
> * I would also love to have PIE as default for Stretch although I fear
>   dpkg-buildflags is the wrong approach for that particular flag.
>
>Thanks,
>~Niels
>
>[1] https://gcc.gnu.org/gcc-6/changes.html
>
>"""The --enable-default-pie configure option enables generation of PIE
>by default."""

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Iustin Pop]

On 2016-05-15 21:45:55, Bálint Réczey wrote:
> Hi Niels,
> 
> 2016-05-15 20:49 GMT+02:00 Niels Thykier :
> > Bálint Réczey:
> >> Hi,
> >>
> >> [...]
> >>
> >
> > Hi,
> >
> >> I think making PIE and bindnow default in dpkg (at least for amd64) would 
> >> be
> >> perfect release goals for Stretch.
> >>
> >
> > I support the end goal, but I suspect we should enable PIE by default
> > via GCC-6's new configure switch[1].  Assuming it does what I hope, then
> > it will work better than enabling PIE via dpkg-buildflags.
> >
> >  * The major issue with PIE by default is that it is not compatible
> >with -fPIC (and presumably also -static), which causes FTBFS or
> >broken ELF binaries.
> >
> >  * Assuming the GCC option does what I hope, then it would automatically
> >disable PIE for irrelevant outputs.
> >
> > My assumption seems to be aligned with the approach taking by Ubuntu.
> 
> I agree that it would be the easier way and I also tried building packages 
> with
> patched GCC 5 setting PIE as default with success, but we have a CTTE
> decision which says that we should set hardening flags through dpkg:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

I'm not familiar with the history of that bug (272 updates!), so excuse
my question, but:

- that bug seems to have been opened in the context of custom patches to
  GCC, back in 2009-2012
- the CTTE seems to have made an informal decision (see last update
  #272) on that topic

Would it make sense to re-evaluate that decision in the context of 2016,
i.e. (if I understand correctly) no patching of GCC 6 needed? Just a
quick ask to the CTTE asking if the decision is still valid given
today's situation.

regards,
iustin

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi Niels,

2016-05-15 20:49 GMT+02:00 Niels Thykier :
> Bálint Réczey:
>> Hi,
>>
>> [...]
>>
>
> Hi,
>
>> I think making PIE and bindnow default in dpkg (at least for amd64) would be
>> perfect release goals for Stretch.
>>
>
> I support the end goal, but I suspect we should enable PIE by default
> via GCC-6's new configure switch[1].  Assuming it does what I hope, then
> it will work better than enabling PIE via dpkg-buildflags.
>
>  * The major issue with PIE by default is that it is not compatible
>with -fPIC (and presumably also -static), which causes FTBFS or
>broken ELF binaries.
>
>  * Assuming the GCC option does what I hope, then it would automatically
>disable PIE for irrelevant outputs.
>
> My assumption seems to be aligned with the approach taking by Ubuntu.

I agree that it would be the easier way and I also tried building packages with
patched GCC 5 setting PIE as default with success, but we have a CTTE
decision which says that we should set hardening flags through dpkg:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

>
>> This would make Debian on par with Fedora and Ubuntu in that regard.
>>
>
> FTR, Fedora seems to have some special logic for adding PIE only to
> executables.
>
>> We briefly discussed that with Guillem in a related bug report:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42
>>
>> I think the next step could be an archive rebuild with the changed defaults
>> if we would like to pursue this:
>> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
>>
>> I planned starting a discussion on debian-devel about PIE + bindnow,
>> too, after checking
>> all the packages which contain statically compiled binaries because
>> they may need patching
>> to disable PIE flags based on Lunar's post:
>> https://people.debian.org/~lunar/blog/posts/aslr_now/
>>
>> Cheers,
>> Balint
>>
>>>[...]
>
> In summary:
>
>  * I would welcome bindnow by default via dpkg-buildflags.
>
>  * I would also love to have PIE as default for Stretch although I fear
>dpkg-buildflags is the wrong approach for that particular flag.

I would be happy with either of the approaches.

Cheers,
Balint

>
> Thanks,
> ~Niels
>
> [1] https://gcc.gnu.org/gcc-6/changes.html
>
> """The --enable-default-pie configure option enables generation of PIE
> by default."""

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Dimitri John Ledkov]

On 15 May 2016 at 19:49, Niels Thykier  wrote:
> Bálint Réczey:
>> Hi,
>>
>> [...]
>>
>
> Hi,
>
>> I think making PIE and bindnow default in dpkg (at least for amd64) would be
>> perfect release goals for Stretch.
>>
>
> I support the end goal, but I suspect we should enable PIE by default
> via GCC-6's new configure switch[1].  Assuming it does what I hope, then
> it will work better than enabling PIE via dpkg-buildflags.
>

The configure switch is available in the debian gcc-5 toolchain as a
cherrypick, which is not used.
In the ubuntu build of the toolchain that switch is passed on
previously mentioned releases / architectures.

FYI, that switch is not perfect and -no-pie has to be used in a few
places still.


>  * The major issue with PIE by default is that it is not compatible
>with -fPIC (and presumably also -static), which causes FTBFS or
>broken ELF binaries.
>
>  * Assuming the GCC option does what I hope, then it would automatically
>disable PIE for irrelevant outputs.
>
> My assumption seems to be aligned with the approach taking by Ubuntu.
>
>> This would make Debian on par with Fedora and Ubuntu in that regard.
>>
>
> FTR, Fedora seems to have some special logic for adding PIE only to
> executables.
>
>> We briefly discussed that with Guillem in a related bug report:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42
>>
>> I think the next step could be an archive rebuild with the changed defaults
>> if we would like to pursue this:
>> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
>>
>> I planned starting a discussion on debian-devel about PIE + bindnow,
>> too, after checking
>> all the packages which contain statically compiled binaries because
>> they may need patching
>> to disable PIE flags based on Lunar's post:
>> https://people.debian.org/~lunar/blog/posts/aslr_now/
>>
>> Cheers,
>> Balint
>>
>>>[...]
>
> In summary:
>
>  * I would welcome bindnow by default via dpkg-buildflags.
>
>  * I would also love to have PIE as default for Stretch although I fear
>dpkg-buildflags is the wrong approach for that particular flag.
>
> Thanks,
> ~Niels
>
> [1] https://gcc.gnu.org/gcc-6/changes.html
>
> """The --enable-default-pie configure option enables generation of PIE
> by default."""
>
>

-- 
Regards,

Dimitri.

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Niels Thykier]

Bálint Réczey:
> Hi,
> 
> [...]
> 

Hi,

> I think making PIE and bindnow default in dpkg (at least for amd64) would be
> perfect release goals for Stretch.
> 

I support the end goal, but I suspect we should enable PIE by default
via GCC-6's new configure switch[1].  Assuming it does what I hope, then
it will work better than enabling PIE via dpkg-buildflags.

 * The major issue with PIE by default is that it is not compatible
   with -fPIC (and presumably also -static), which causes FTBFS or
   broken ELF binaries.

 * Assuming the GCC option does what I hope, then it would automatically
   disable PIE for irrelevant outputs.

My assumption seems to be aligned with the approach taking by Ubuntu.

> This would make Debian on par with Fedora and Ubuntu in that regard.
> 

FTR, Fedora seems to have some special logic for adding PIE only to
executables.

> We briefly discussed that with Guillem in a related bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42
> 
> I think the next step could be an archive rebuild with the changed defaults
> if we would like to pursue this:
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
> 
> I planned starting a discussion on debian-devel about PIE + bindnow,
> too, after checking
> all the packages which contain statically compiled binaries because
> they may need patching
> to disable PIE flags based on Lunar's post:
> https://people.debian.org/~lunar/blog/posts/aslr_now/
> 
> Cheers,
> Balint
> 
>>[...]

In summary:

 * I would welcome bindnow by default via dpkg-buildflags.

 * I would also love to have PIE as default for Stretch although I fear
   dpkg-buildflags is the wrong approach for that particular flag.

Thanks,
~Niels

[1] https://gcc.gnu.org/gcc-6/changes.html

"""The --enable-default-pie configure option enables generation of PIE
by default."""




signature.asc
Description: OpenPGP digital signature

PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi,

2016-05-15 4:11 GMT+02:00 Dimitri John Ledkov :
> On 14 May 2016 at 21:12, Niels Thykier  wrote:
>> Marco d'Itri:
>>> On May 03, Josh Triplett  wrote:
>>>
 While this doesn't make PIC absolutely free, it does eliminate almost
 all of the cost, to the point that it no longer seems worthwhile to
 build without -fPIC.  Apart from that, building *all* code with -fPIC
 (including both programs and libraries) helps with hardening.
>>> I think that this is worth exploring.
>>> Did you check what other (relevant) distributions are doing?
>>>
>>
>> Fedora seems to be doing -fPIE by default for executables[1] - targeting
>> Fedora 23.  Known issues they ran into can be found at [2].
>>   I also found the following PPA [3]. Cannot say if it is official or
>> just a personal interest from the PPA owner.
>>
>
> Ubuntu 16.04 LTS on s390x has -fPIE and bind now
>
> Ubuntu 16.10 on amd64, ppc64el, s390x has -fPIE and bind now

I think making PIE and bindnow default in dpkg (at least for amd64) would be
perfect release goals for Stretch.

This would make Debian on par with Fedora and Ubuntu in that regard.

We briefly discussed that with Guillem in a related bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42

I think the next step could be an archive rebuild with the changed defaults
if we would like to pursue this:
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F

I planned starting a discussion on debian-devel about PIE + bindnow,
too, after checking
all the packages which contain statically compiled binaries because
they may need patching
to disable PIE flags based on Lunar's post:
https://people.debian.org/~lunar/blog/posts/aslr_now/

Cheers,
Balint

>
> In general features like these for Ubuntu are tracked by Security team at:
>
> https://wiki.ubuntu.com/Security/Features
>
> And bind-now needs fixing on that page.
>
> --
> Regards,
>
> Dimitri.
>