[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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 <niels@thykier.net>:
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


Reply to: