Re: Porter roll call for Debian Stretch
On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote: > Over all, most people (who answered it) was positive towards the switch. > Based on this, I suspect that if we make PIE default in Stretch, then > we will do it for all architectures. That said, you will be notified if > that default changes for Stretch. Is this just for ASLR, or is ther another motivating factor for PIE? AFAIK Address space randomizing is not really helpful on 32 bit architectures - there is just not that many places to randomize to[1]. At least previously, PIE added ~10% to binary size, which can have a major performance impact on the 32-bit arm core's that don't have much cache to begin with. Riku [1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf
Re: Porter roll call for Debian Stretch
On 09/21/2016 08:41 AM, Riku Voipio wrote: > AFAIK Address space randomizing is not really helpful on 32 bit > architectures - there is just not that many places to randomize to[1]. Well, sure, but there's still a huge difference in an explot with 100% reliability, or an exploit that will just crash the program in 95% of cases. Sure, if there's an easy way to repeatedly try the exploit 20 times, it won't be a show-stopper, but it will make the life of people who want to exploit a flaw just a tiny bit harder. > At least previously, PIE added ~10% to binary size, At least on x86 there have been substantial improvements in receent gcc versions when it comes to PIE support, so the impact of PIE on executables even on 32bit is a lot smaller than it used to be. I don't know about ARM though. Consider the following two data points: - A _lot_ of code in Debian is in shared libraries, which are compiled with -fPIC anyway. Many executables only spend a fraction of their instructions in the executable code itself. - It's been considered best practice to enable PIE executables if possible (via hardening=+all or similar), so many programs in Debian (and e.g. all of my packages except one) already use that. I suspect that a lot of of code that you are currently running is already PIE, especially in the packages that are more actively maintained. Regards, Christian
Bug#838447: gtk+3.0: Please build documentation packages in binary-indep target
Source: gtk+3.0 Version: 3.22.0-1 Severity: normal Hi! Currently, src:gtk+3.0 builds its documentation on all architectures which is rather sub-optimal as this particular step in the build process is rather time-consuming due to the fact that large XML files are parsed. Additionally, the binary invoked, gtkdoc-mkhtml, also causes trouble when building src:gtk+3.0 on architectures like m68k where we are using qemu: cd html && gtkdoc-mkhtml $mkhtml_options "--path=\"/build/gtk+3.0-TswWzT/gtk+3.0-3.22.0/./docs/reference/gtk:/build/gtk+3.0-TswWzT/gtk+3.0-3.22.0/./examples\"" gtk3 ../gtk-docs.sgml Makefile:549: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Terminated Makefile:1370: recipe for target 'html-build.stamp' failed make[5]: *** [html-build.stamp] Terminated Makefile:547: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Terminated /usr/share/cdbs/1/class/makefile.mk:77: recipe for target 'debian/stamp-makefile-build/shared' failed make: *** [debian/stamp-makefile-build/shared] Terminated E: Caught signal ‘Terminated’: terminating immediately Makefile:722: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Terminated Makefile:616: recipe for target 'all' failed make[1]: *** [all] Terminated E: Build killed with signal TERM after 60 minutes of inactivity In order to get src:gtk+3.0 build on the affected architectures, I usually edit the debian/rules file and disable the documentation by adding the configure option '--disable-gtk-doc' to DEB_CONFIGURE_FLAGS_shared. It would therefore be a good idea to build the documentation in the binary-indep target in debian/rules only. This way, we would avoid issues like the one above in the future and we also save quite a lot of build time on the slower buildds. Thanks for considering! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913