Re: Enabling PIE by default for Stretch

2016-10-10 Thread Bálint Réczey
Hi Maximiliano,

2016-10-10 14:21 GMT+02:00 Maximiliano Curia :
> ¡Hola Niels!
>
> El 2016-10-10 a las 05:44 +, Niels Thykier escribió:
>>
>> Niels Thykier:
>>>
>>> As brought up on the meeting last night, I think we should try to go for
>>> PIE by default in Stretch on all release architectures!  * It is a
>>> substantial hardening feature  * Upstream has vastly reduced the performance
>>> penalty for x86  * The majority of all porters believe their release
>>> architecture isready for it.  * We have sufficient time to solve any
>>> issues or revert if it turns outto be too problematic.
>
>
>>> [...]
>
>
>>>  * Deadline for major concerns:  Fri, 7th of October 2016.
>
>
>> It appears that there were no major concerns.  I will follow up #835148
>> and request PIE by default for the following architectures.
>
>
>> * amd64 * arm64 * armel * armhf * i386 * mips * mips64el * mipsel *
>> ppc64el * s390x
>
>
> Such a change will produce unneeded FTBFS's in libraries using -fPIC (such
> as qt5 and all it's dependencies).
>
> Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible
> with -fPIC and -fPIE makes little sense in shared libraries.
>
> And while a single patch should be trivial, I fear they would be many
> specific ones.

Have you seen the results of the test-rebuild performed with the
changed defaults?

I have put together a page with related links and information where
you can find the rebuild results, too:

 https://wiki.debian.org/Hardening/PIEByDefaultTransition

Cheers,
Balint



Re: Enabling PIE by default for Stretch

2016-10-10 Thread Maximiliano Curia

¡Hola Niels!

El 2016-10-10 a las 05:44 +, Niels Thykier escribió:

Niels Thykier:
As brought up on the meeting last night, I think we should try to go for 
PIE by default in Stretch on all release architectures! 
 * It is a substantial hardening feature 
 * Upstream has vastly reduced the performance penalty for x86 
 * The majority of all porters believe their release architecture is 
   ready for it. 
 * We have sufficient time to solve any issues or revert if it turns out 
   to be too problematic.



[...]



 * Deadline for major concerns:  Fri, 7th of October 2016.


It appears that there were no major concerns.  I will follow up #835148 
and request PIE by default for the following architectures.


* amd64 
* arm64 
* armel 
* armhf 
* i386 
* mips 
* mips64el 
* mipsel 
* ppc64el 
* s390x


Such a change will produce unneeded FTBFS's in libraries using -fPIC (such as 
qt5 and all it's dependencies).


Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible 
with -fPIC and -fPIE makes little sense in shared libraries.


And while a single patch should be trivial, I fear they would be many specific 
ones.


Happy hacking,
--
"If a thing is done wrong often enough, it becomes right" -- Leahy's Law
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature


Re: Enabling PIE by default for Stretch

2016-10-09 Thread Niels Thykier
Niels Thykier:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> [...]
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> [...]
> 
> Thanks,
> ~Niels
> 
> [...]

It appears that there were no major concerns.  I will follow up #835148
and request PIE by default for the following architectures.

 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mips64el
 * mipsel
 * ppc64el
 * s390x

Should you be a porter for an architecture not listed above and want PIE
by default on your architecture, please follow up on #835148 as well (or
a file a new wishlist bug if #835148 is closed when you do it)

NB: The omission of powerpc was intentional as there were no porters
supporting it during the roll-call.

Thanks,
~Niels





Re: Enabling PIE by default for Stretch

2016-09-30 Thread Matthias Klose
[CCing porters, please also leave feedback in #835148 for non-release 
architectures]

On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> As agreed on during the [meeting], if there are no major concerns to
> this proposal in general within a week, I shall file a bug against GCC
> requesting PIE by default on all release architectures (with backing
> porters).

please re-use #835148

>   If there are only major concerns with individual architectures, I will
> simply exclude said architectures in the "PIE by default" request.
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> Fall-out
> 
> 
> There will be some possible fall-out from this change:
> 
>  * There will be some FTBFS caused by some packages needing a rebuild
>before reverse dependencies can enable PIE.  These are a subset of
>the bugs filed in the [pie+bindnow] build tests.
> 
>  * Some packages may not be ready for PIE.  These will have to disable
>it per package.  A notable case being ghc (#712228), where we can
>reuse the patch from Ubuntu to work around the issue.
> 
>  * A possible issue from Matthias was that no one has done a large scale
>"PIE by default" on "arm* mips*".
> 
>  * There was concern about whether the 32bit arm architectures would be
>notably affected by the PIE slow down (like x86 used to be).
>It is not measured, but two arm porters did mention a possible
>slowdown
> 
>  * It was questioned whether it made sense to invest time and effort in
>enabling PIE for architectures which would not be included in Buster
>(armel?). Personally, I do not see an issue, if the porters are
>ready to put in the effort required.
> 
> Thanks,
> ~Niels
> 
> [meeting]:
> http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html
> 
> [pie+bindnow]:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906&users=balint%40balintreczey.hu;dist=unstable
> 
> 
> 
>