Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 02:22 PM, Jakub Jelinek wrote: On Mon, Jan 19, 2015 at 01:59:32PM +0100, Florian Weimer wrote: It is an ABI change. IMHO very much undesirable. Just complain to people that build their packages without it where it matters. Some core libraries use off_t or struct stat in public header files, so we already have the ABI problem. Paul Eggert did some review and thinks that 64-bit-by-default fixes more things than it breaks: https://sourceware.org/ml/libc-alpha/2014-03/msg00670.html In addition, selinux/selinux.h contains this gem: extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); Yeah, perhaps some packages do bogus and unsafe things. But by changing _FILE_OFFSET_BITS, you change it silently for everything. C++ functions using ino_t/off_t etc. will not link anymore, ... You'd need to bump SONAME of all the affected shared libraries, etc. IMNSHO you can do this kind of changes in a new port, but not afterwards. That was my initial reaction back then as well, but after Paul Eggert's analysis, I'm not so sure anymore. We already have quite a bit breakage, but maybe it is restricted to corner cases only. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 04:17 PM, Peter Robinson wrote: As far as I can tell, OLPC does not ship newer Fedora releases through their updater, so what we do in Fedora does not make any difference at all to OLPC users. That's not entirely correct, they don't yet have F-21 but they do have recent F-20 builds. End-user-installable? Where? Can you point me to the update instructions? Yes, you can get the latest F-20 here http://wiki.laptop.org/go/14.1.0 Thanks, I was confused by the chaotic sorting on their release page, which made it look like the updates ceased some time in 2011. So at least some GUI-ish things also see testing on SSE2-less machines (plus the x86-compatible heating devices others reported to run). And this makes disabling SSE2 not feasible at this point. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 01:21 PM, Florian Weimer wrote: On 01/19/2015 01:17 PM, Alexander Ploumistos wrote: On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com mailto:fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. Fedora 21 is working without any problems on these: # cat /proc/cpuinfo ... model name : Pentium III (Coppermine) ... flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse ... # cat /etc/fedora-release Fedora release 21 (Twenty One) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/09/2015 12:16 AM, Dennis Gilmore wrote: at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. As far as I can tell, OLPC does not ship newer Fedora releases through their updater, so what we do in Fedora does not make any difference at all to OLPC users. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 19/01/15 12:21, Florian Weimer wrote: On 01/19/2015 01:17 PM, Alexander Ploumistos wrote: On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com mailto:fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. I have a PIII running F21 in production that doesn't support SSE2... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/07/2015 02:30 PM, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? GCC 5 and recent binutils support copy relocations, so the performance impact of PIE is reduced even further. I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 1:19 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.01.2015 um 13:17 schrieb Alexander Ploumistos: On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com mailto:fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? how would that matter? http://en.wikipedia.org/wiki/SSE2 introduced by Intel with the initial version of the Pentium 4 in 2001 Sure but it would exclude all non AMD64 Amd CPUs (introduced in 2003) and Pentium 3 ... whether there is userbase for tha or not t (or how large it is) I don't know ... -E_NO_DATA. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 19.01.2015 um 13:23 schrieb Alexander Ploumistos: On Mon, Jan 19, 2015 at 2:21 PM, Florian Weimer wrote: Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. OK, thanks. Guess I'll have to switch my PIII and Athlon MP relics to something like Gentoo or Arch to be honest - the energy these old machines have wasted the last years could have payed recent hardware and the combination of a bleeding edge distribution and more than a decade old hardware is questionable signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. As far as I can tell, OLPC does not ship newer Fedora releases through their updater, so what we do in Fedora does not make any difference at all to OLPC users. That's not entirely correct, they don't yet have F-21 but they do have recent F-20 builds. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 01:41 PM, Jakub Jelinek wrote: On Mon, Jan 19, 2015 at 01:37:29PM +0100, Florian Weimer wrote: On 01/19/2015 01:15 PM, Jakub Jelinek wrote: No, because you need GCC 5 for that (ok, have scratch rpms now for that), and very recent binutils (2.25 we have in F22 is not enough). Ugh, this seems to suggests to defer the PIE change to Fedora 23. :-( As F22 mass rebuild has been denied by FESCO, that is given anyway. Meh, okay. Would it still make sense to proceed with SSE2 and the off_t/ino_t change? -msse2 is discussion whether it is worth it. In RHEL7 we default to that, but in Fedora, given the whole i?86 port is kind of legacy/obsolete now anyway, it might be undesirable. Well, unless there are testers who run Fedora on non-SSE2 hardware, it's very likely broken these days anyway. And, making _FILE_OFFSET_BITS=64 the default? How do you turn it off? In general, you don't. :-) But you could define it to 32 instead. It is an ABI change. IMHO very much undesirable. Just complain to people that build their packages without it where it matters. Some core libraries use off_t or struct stat in public header files, so we already have the ABI problem. Paul Eggert did some review and thinks that 64-bit-by-default fixes more things than it breaks: https://sourceware.org/ml/libc-alpha/2014-03/msg00670.html In addition, selinux/selinux.h contains this gem: extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Hi, Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. See other replies, people are running such machines. Given x86_64 exists for many years and even embedded (see aarch64) is moving to 64bit these days i386 clearly is for old legacy hardware. If you need performance you don't run a i386 machine. So, why bother raising the bar for i386 by requiring more cpu features? It doesn't help anyone. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 2:32 PM, Reindl Harald h.rei...@thelounge.net wrote: to be honest - the energy these old machines have wasted the last years could have payed recent hardware and the combination of a bleeding edge distribution and more than a decade old hardware is questionable That is definitely true for the Athlon MP system, just the cooling fans require ~60 Watts. On the other hand, the PIII functions as a file/vpn/ftp server and usually draws about 20W. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 01:37:29PM +0100, Florian Weimer wrote: On 01/19/2015 01:15 PM, Jakub Jelinek wrote: No, because you need GCC 5 for that (ok, have scratch rpms now for that), and very recent binutils (2.25 we have in F22 is not enough). Ugh, this seems to suggests to defer the PIE change to Fedora 23. :-( As F22 mass rebuild has been denied by FESCO, that is given anyway. Would it still make sense to proceed with SSE2 and the off_t/ino_t change? -msse2 is discussion whether it is worth it. In RHEL7 we default to that, but in Fedora, given the whole i?86 port is kind of legacy/obsolete now anyway, it might be undesirable. And, making _FILE_OFFSET_BITS=64 the default? How do you turn it off? It is an ABI change. IMHO very much undesirable. Just complain to people that build their packages without it where it matters. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 01:59:32PM +0100, Florian Weimer wrote: It is an ABI change. IMHO very much undesirable. Just complain to people that build their packages without it where it matters. Some core libraries use off_t or struct stat in public header files, so we already have the ABI problem. Paul Eggert did some review and thinks that 64-bit-by-default fixes more things than it breaks: https://sourceware.org/ml/libc-alpha/2014-03/msg00670.html In addition, selinux/selinux.h contains this gem: extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); Yeah, perhaps some packages do bogus and unsafe things. But by changing _FILE_OFFSET_BITS, you change it silently for everything. C++ functions using ino_t/off_t etc. will not link anymore, ... You'd need to bump SONAME of all the affected shared libraries, etc. IMNSHO you can do this kind of changes in a new port, but not afterwards. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 3:03 PM, Florian Weimer fwei...@redhat.com wrote: On 01/19/2015 03:08 PM, Peter Robinson wrote: at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. As far as I can tell, OLPC does not ship newer Fedora releases through their updater, so what we do in Fedora does not make any difference at all to OLPC users. That's not entirely correct, they don't yet have F-21 but they do have recent F-20 builds. End-user-installable? Where? Can you point me to the update instructions? Yes, you can get the latest F-20 here http://wiki.laptop.org/go/14.1.0 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 03:08 PM, Peter Robinson wrote: at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. As far as I can tell, OLPC does not ship newer Fedora releases through their updater, so what we do in Fedora does not make any difference at all to OLPC users. That's not entirely correct, they don't yet have F-21 but they do have recent F-20 builds. End-user-installable? Where? Can you point me to the update instructions? -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann: Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. See other replies, people are running such machines. Given x86_64 exists for many years and even embedded (see aarch64) is moving to 64bit these days i386 clearly is for old legacy hardware. If you need performance you don't run a i386 machine. So, why bother raising the bar for i386 by requiring more cpu features? It doesn't help anyone. rpmrc has optflags: for different architectures so why not optimize only optflags: x86_64 for more recent hardware? since i686 is a complete different build anyways it won't matter on my private builders it's -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -mfpmath=sse for a long time and will become -mavx -mfpmath=avx after replace the oldest servers from 2010 with SandyBridge or newer based Xeons this year (any workstations are SandyBridge/IvyBrdige already) and -march=corei7-avx -mtune=corei7-avx too signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/09/2015 12:54 PM, Jakub Jelinek wrote: Also, the number of relocations and memory consumption got up. Non-PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries: Relocation section '.rela.plt' at offset 0x188f00 contains 284 entries: GNU_RELRO 0x1d14730 0x02314730 0x02314730 0x0058d0 0x0058d0 R 0x1 PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d90 contains 75803 entries: Relocation section '.rela.plt' at offset 0x344018 contains 230 entries: GNU_RELRO 0x1e18cf0 0x02018cf0 0x02018cf0 0x10e310 0x10e310 R 0x1 That means e.g. on the startup of each cc1plus process, that means 1MB extra COW wastage (executable has 24KB of pages written and then made non-writable, while PIE over 1MB). Odd. Did you test with copy relocations enabled? -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 01:17 PM, Alexander Ploumistos wrote: On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com mailto:fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 01:11:19PM +0100, Florian Weimer wrote: On 01/09/2015 12:54 PM, Jakub Jelinek wrote: Also, the number of relocations and memory consumption got up. Non-PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries: Relocation section '.rela.plt' at offset 0x188f00 contains 284 entries: GNU_RELRO 0x1d14730 0x02314730 0x02314730 0x0058d0 0x0058d0 R 0x1 PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d90 contains 75803 entries: Relocation section '.rela.plt' at offset 0x344018 contains 230 entries: GNU_RELRO 0x1e18cf0 0x02018cf0 0x02018cf0 0x10e310 0x10e310 R 0x1 That means e.g. on the startup of each cc1plus process, that means 1MB extra COW wastage (executable has 24KB of pages written and then made non-writable, while PIE over 1MB). Odd. Did you test with copy relocations enabled? No, because you need GCC 5 for that (ok, have scratch rpms now for that), and very recent binutils (2.25 we have in F22 is not enough). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 19.01.2015 um 13:17 schrieb Alexander Ploumistos: On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com mailto:fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? how would that matter? http://en.wikipedia.org/wiki/SSE2 introduced by Intel with the initial version of the Pentium 4 in 2001 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/19/2015 01:15 PM, Jakub Jelinek wrote: No, because you need GCC 5 for that (ok, have scratch rpms now for that), and very recent binutils (2.25 we have in F22 is not enough). Ugh, this seems to suggests to defer the PIE change to Fedora 23. :-( Would it still make sense to proceed with SSE2 and the off_t/ino_t change? -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 2:21 PM, Florian Weimer fwei...@redhat.com wrote: Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. OK, thanks. Guess I'll have to switch my PIII and Athlon MP relics to something like Gentoo or Arch. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Jan 2015 12:58:06 +0100 Florian Weimer fwei...@redhat.com wrote: On 01/07/2015 02:30 PM, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? GCC 5 and recent binutils support copy relocations, so the performance impact of PIE is reduced even further. I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Fedoraś minimally supported 32 bit system that has a massive (in the millions of units) deployments is the OLPC XO-1 which does not have sse at all. so you would be cutting off the largest part of 32 bit fedora deployments. you also fail to cover armv7hl or any of the secondary arches in your proposal. At the least you need to say its x86 only but you should evaluate all supported fedora arches. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUvUMDAAoJEH7ltONmPFDRnzIQAKsWEgRq+F9lyJsALB8je7kz 4RNg0A4nGOTJAjN1FvDiSR8M+1Y+AfYu+N/YEDmHcTP1AFNZQZHmXcm2vr6Sy5uw eg2QiZdkQaBWVbtZP1/XnNRhauVj7Whl7+RyX1pDAzQaJr1xZ4xBmtDSSLwRJA/H z30gm9aCzxyupY58FCDhvBRfAy3BwuNSCiT9PGEXLGA3Yu9XbkozeqqUw6n+vM7i yo65Fa6XAEfulwvqVhbZhttTDdIwNTRkk2znqoovlBEpEaPk9Cl2Qb7/xriQVA79 Vq/dNjanSummoThMrITlFZrAGMjcKOvKruvg3zEOiOwrIlfz4VeS2fw6SPFpmU3E d/fvuPOy+jb0h69gAchQlGabDNkJwzwqwG+pW4sv9DLa4uEjDPoMYI8cHbc21DIw NJU3vMWCYQpS2VJNJ3lx43v2WTpkC1Cymr5gl9NTQFivJMfdd2Sm/T6UnssCmNDt qOjCsxancsf2nEUZMP/E+EaygH8FW/eOKpQF2SPEKLVKY9AC2cjsfqkHiEkbXQGI fc2Fb21a2so8N+xrN7/MjtJZk+m2xh3xvnbQZ/FpYiV/BN2y89CQN0mzfqOGBwaC 9pbePmTIypXzjshqyJewrPO1oXUD8iY0L1Ia2vhA9korxOGYZLee0gdc4s5LFWdA d4W+Hn9VZ5sn6nEi8H3+ =zkmK -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 19.01.2015 13:21, Florian Weimer wrote: On 01/19/2015 01:17 PM, Alexander Ploumistos wrote: On Mon, Jan 19, 2015 at 1:58 PM, Florian Weimer fwei...@redhat.com mailto:fwei...@redhat.com wrote: I wrote a slightly broader proposal, also covering SSE2 (for i386), and (since today) off_t and ino_t: https://fedoraproject.org/wiki/Changes/Modernise_GCC_Flags Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. These machines are still alive and kicking. You are free to keep Streaming SIMD Extensions 2 for for yourself. Bonne nuit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 3:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann: Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. See other replies, people are running such machines. Given x86_64 exists for many years and even embedded (see aarch64) is moving to 64bit these days i386 clearly is for old legacy hardware. If you need performance you don't run a i386 machine. So, why bother raising the bar for i386 by requiring more cpu features? It doesn't help anyone. rpmrc has optflags: for different architectures so why not optimize only optflags: x86_64 for more recent hardware? since i686 is a complete different build anyways it won't matter on my private builders it's -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -mfpmath=sse Because that doesn't make sense for multiple reasons: 1) mmx is basically obsolete 2) sse2 is the default fp ABI on x86_64 anyway and thus supported by *all* x86_64 cpus 3) Requiring sse4.2 or even 4.1 would exclude a lot of hardware 4) You don't just throw in some compiler flags and assume it will gain you anything (you'd probably have to either turn on O3 or vectorization as well) .. most applications where it really matters do detection at runtime (even glibc does that) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 19.01.2015 um 21:34 schrieb drago01: On Mon, Jan 19, 2015 at 3:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann: Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. See other replies, people are running such machines. Given x86_64 exists for many years and even embedded (see aarch64) is moving to 64bit these days i386 clearly is for old legacy hardware. If you need performance you don't run a i386 machine. So, why bother raising the bar for i386 by requiring more cpu features? It doesn't help anyone. rpmrc has optflags: for different architectures so why not optimize only optflags: x86_64 for more recent hardware? since i686 is a complete different build anyways it won't matter on my private builders it's -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -mfpmath=sse Because that doesn't make sense for multiple reasons: you show none below because it said keep i686 flags unchanged 1) mmx is basically obsolete in theory 2) sse2 is the default fp ABI on x86_64 anyway and thus supported by *all* x86_64 cpus so be it 3) Requiring sse4.2 or even 4.1 would exclude a lot of hardware did i propose that? i said private builders to show that keep supporting 10 years old hardware is just silly because you waste HW capabilities - noweher did i propose *that* falgs 4) You don't just throw in some compiler flags and assume it will gain you anything (you'd probably have to either turn on O3 or vectorization as well) -O3 is the default for my builds starting with 2006 .. most applications where it really matters do detection at runtime (even glibc does that) the topic is still: hwta can be changed in the x86_64 flags *without* break old 32bit crap some people rely for several reasons signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 19, 2015 at 9:41 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.01.2015 um 21:34 schrieb drago01: On Mon, Jan 19, 2015 at 3:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.01.2015 um 15:28 schrieb Gerd Hoffmann: Would that make it impossible to run fedora on sse-only i686 CPUs? Yes, but test coverage for those CPUs is already rather poor, so I don't expect them to work anymore. See other replies, people are running such machines. Given x86_64 exists for many years and even embedded (see aarch64) is moving to 64bit these days i386 clearly is for old legacy hardware. If you need performance you don't run a i386 machine. So, why bother raising the bar for i386 by requiring more cpu features? It doesn't help anyone. rpmrc has optflags: for different architectures so why not optimize only optflags: x86_64 for more recent hardware? since i686 is a complete different build anyways it won't matter on my private builders it's -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -mfpmath=sse Because that doesn't make sense for multiple reasons: you show none below because it said keep i686 flags unchanged 1) mmx is basically obsolete in theory And in practice. Why would you want to use mmx if you have sse2+ available? (you don't). 2) sse2 is the default fp ABI on x86_64 anyway and thus supported by *all* x86_64 cpus so be it 3) Requiring sse4.2 or even 4.1 would exclude a lot of hardware did i propose that? It wasn't clear from your mail what your proposal actually is. i said private builders to show that keep supporting 10 years old hardware is just silly because you waste HW capabilities - noweher did i propose *that* falgs 4) You don't just throw in some compiler flags and assume it will gain you anything (you'd probably have to either turn on O3 or vectorization as well) -O3 is the default for my builds starting with 2006 .. most applications where it really matters do detection at runtime (even glibc does that) the topic is still: hwta can be changed in the x86_64 flags *without* break old 32bit crap some people rely for several reasons OK .. well there is no reason why the flags have to be shared between x86_64 and the 32bit crap ... if you stop carring about 32bit *hardware* we could use sse2 just fine for i686 (people using 32bit applications on top of x86_64 would benefit from it). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones rjo...@redhat.com wrote: Does this proposal apply to native non-C/C++ programs? Rich. I would like to see this proposal apply to native non-C/C++ programs, but I am not sure on how that would be done? Do the other compilers understand what needs to be done when they are passed '-fPIC -pie' flags? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
- Original Message - Does this proposal apply to native non-C/C++ programs? As written, it seems to intend so. In practice, it would probably apply or not depending on whether the non-C/C++ programs’ builds are affected by _hardened_build. Ideally, I think this should apply to all languages that don’t ensure memory safety, and not to those that do ensure it.¹ (There is also the edge case of safe languages with explicit “unsafe” blocks, I guess these should default into the “safe” category?) Mirek ¹ This should not be much of an issue for processes that mix components written in multiple languages because the dynamically loaded libraries / modules have to already by position-independent; we are only discussing the main executable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
That said, even on x86_64 it isn't anything close to no overhead. Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then rebuild stage3 of GCC with make -j1 separately with the original stage3 cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which included still time for various other tools being not PIE, make, ld, as) got 2.1% slower user time. Thanks, this would probably be the first significant example of a really affected program: ( https://fedorahosted.org/fesco/ticket/1113#comment:9 ) 1. Built in the distribution 2. CPU-bound (or CPU-limited in the primary performance metric) 3. Not required use PIE already (= not running as root, not a daemon) 4. (added): Not having the CPU-bound part in a shared library, like firefox or libreoffice¹ do. How many other such programs are there? If all we are talking about is increased program build times, that is IMHO _well_ worth the security mitigations. Mirek ¹ (Both Firefox and LibreOffice are disqualified through 3. anyway.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote: - Original Message - Does this proposal apply to native non-C/C++ programs? As written, it seems to intend so. In practice, it would probably apply or not depending on whether the non-C/C++ programs’ builds are affected by _hardened_build. I did not think of these programs, so I agree here. Addressing them is something for a future change proposal IMHO, unless there is enough time to to do for F22. Ideally, I think this should apply to all languages that don’t ensure memory safety, and not to those that do ensure it.¹ (There is also the edge case of safe languages with explicit “unsafe” blocks, I guess these should default into the “safe” category?) Mirek Is there a list of languages that need to be considered? There is afaik golang, ocaml and ghc that need to be considered. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 12, 2015 at 10:57:50AM -0800, Moez Roy wrote: On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones rjo...@redhat.com wrote: Does this proposal apply to native non-C/C++ programs? Rich. I would like to see this proposal apply to native non-C/C++ programs, but I am not sure on how that would be done? Do the other compilers understand what needs to be done when they are passed '-fPIC -pie' flags? OCaml has -fPIC. However I don't know how/if it's possible to enable PIE on the main executable. I will need to check when I'm back from holiday. OCaml is a memory safe language, so a pure OCaml program just doesn't suffer from the same kinds of problems that C programs do. However pure OCaml programs aren't very common - we often link to or write parts of the program in C, and there things get a bit more complicated. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Tue, Jan 13, 2015 at 7:31 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote: On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote: - Original Message - Does this proposal apply to native non-C/C++ programs? As written, it seems to intend so. In practice, it would probably apply or not depending on whether the non-C/C++ programs’ builds are affected by _hardened_build. I did not think of these programs, so I agree here. Addressing them is something for a future change proposal IMHO, unless there is enough time to to do for F22. Ideally, I think this should apply to all languages that don’t ensure memory safety, and not to those that do ensure it.¹ (There is also the edge case of safe languages with explicit “unsafe” blocks, I guess these should default into the “safe” category?) Mirek Is there a list of languages that need to be considered? There is afaik golang, ocaml and ghc that need to be considered. Probably Ada (ie. gnat), Fortran (gfortran), ObjC. Are there any other gcc frontends? LDC (D) can generate native binaries too. clang there is at least one package that has a build with clang exception iirc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote: On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote: - Original Message - Does this proposal apply to native non-C/C++ programs? As written, it seems to intend so. In practice, it would probably apply or not depending on whether the non-C/C++ programs’ builds are affected by _hardened_build. I did not think of these programs, so I agree here. Addressing them is something for a future change proposal IMHO, unless there is enough time to to do for F22. Ideally, I think this should apply to all languages that don’t ensure memory safety, and not to those that do ensure it.¹ (There is also the edge case of safe languages with explicit “unsafe” blocks, I guess these should default into the “safe” category?) Mirek Is there a list of languages that need to be considered? There is afaik golang, ocaml and ghc that need to be considered. Probably Ada (ie. gnat), Fortran (gfortran), ObjC. Are there any other gcc frontends? LDC (D) can generate native binaries too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Hi, I've been testing in advance to make mass rebuilds changing macros and the results are pretty good (I mean x86_64 f20, f21 + grsecurity custom kernels). It is clear that we will find regressions, we just have to start and test it.. It is an important and necessary change. If anyone is interested would be important to look at uClibc and musl (Alpine Linux is based in this one). http://www.etalabs.net/compare_libcs.html Note that other distributions are doing an excellent job in hardened profiles like Gentoo or more actual OpenSuSe Gardened: http://wiki.gentoo.org/wiki/Project:Hardened_musl http://wiki.gentoo.org/wiki/Project:Hardened_uClibc https://github.com/kdave/openSUSE-gardened/wiki/openSUSE-gardened We have to work on mitigation rather than patching and trust not responsible maintainers for some packages. This includes thinking seriously about to have a kernel with grsecurity patches. Cheers, On Sat, Jan 10, 2015 at 4:19 PM, Peter Robinson pbrobin...@gmail.com wrote: On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote: On Thu, 8 Jan 2015, Dhiru Kholia wrote: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. Can we throw prelink out as well when we do this? Prelink is already gone. We haven't been running it since F19, IIRC. It's not completely gone, there's still a number of packages that run it as part of the install or build process because I've had to fix ppc64le/aarchh64 package builds because we don't have it at all on those platforms. I think we also ship it by default. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Francisco Alonso. http://twitter.com/revskills PGP: 0xE2E64DCA -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote: On Thu, 8 Jan 2015, Dhiru Kholia wrote: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. Can we throw prelink out as well when we do this? Prelink is already gone. We haven't been running it since F19, IIRC. It's not completely gone, there's still a number of packages that run it as part of the install or build process because I've had to fix ppc64le/aarchh64 package builds because we don't have it at all on those platforms. I think we also ship it by default. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Sat, Jan 10, 2015 at 03:19:28PM +, Peter Robinson wrote: On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote: On Thu, 8 Jan 2015, Dhiru Kholia wrote: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. Can we throw prelink out as well when we do this? Prelink is already gone. We haven't been running it since F19, IIRC. It's not completely gone, there's still a number of packages that run it as part of the install or build process because I've had to fix ppc64le/aarchh64 package builds because we don't have it at all on those platforms. I think we also ship it by default. Note that the prelink package contains a useful utility called execstack. We used to use this on OCaml programs to fix executable stack flags (but not lately, since I patched the OCaml compiler to do the right thing). So you may have seen a dependency on prelink which wasn't really about prelink. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Does this proposal apply to native non-C/C++ programs? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On 01/09/2015 04:05 AM, Reindl Harald wrote: *but* since *mobile phones* and other operating systems in the meantime are full PIE and it improves security how can someone justify the reason performance on a desktop/server distribution with much more powerful hardware? Often the usage statistics are vastly different. A mobile phone might instantiate a module (main program or shared library) a few thousand times per day, while a desktop/server often instantiates a module many thousand times per minute. Thus the initial costs of processing the relocation table often do not matter on the phone, but can be significant on the desktop/server. Modifying the relocation table of a PIE/PIC module costs a page of RAM. This can matter in a small VM that has only 256MB or 512MB of RAM. On a phone the net cost can be zero because if the pre-image is kept compressed then often every page in the process image is new anyway. A desktop/server usually stores most modules uncompressed and shareable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Fri, Jan 09, 2015 at 06:01:14PM +0100, Reindl Harald wrote: I don't want to go the road where press articles say a specific bug in software XYZ available for Linux, BSD and OSX would have only on Fedora not been mitigated because we still discuss over performance impacts while others already went ahead https://fedoraproject.org/wiki/Foundations First represents our commitment to innovation I would welcome Fedora be first in things like this topic instead as often in the past replace already working things with unfinished alpha quality and need 3 follow-up releases to get back from where it came and praise new things which are in fact regression-fixes and features which where there before the replacements Agreed. Too much time has been wasted on pointless discussion over this. Let's enable this, rebuild packages, and if there are regressions - either change to non-pie for specific packages - or revert the change. Microbenchmarks get us only so far, we need to know the impact the change makes for the whole system. We won't know that until enough packages have been rebuilt. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 09.01.2015 um 16:56 schrieb John Reiser: On 01/09/2015 04:05 AM, Reindl Harald wrote: *but* since *mobile phones* and other operating systems in the meantime are full PIE and it improves security how can someone justify the reason performance on a desktop/server distribution with much more powerful hardware? Often the usage statistics are vastly different. A mobile phone might instantiate a module (main program or shared library) a few thousand times per day, while a desktop/server often instantiates a module many thousand times per minute. Thus the initial costs of processing the relocation table often do not matter on the phone, but can be significant on the desktop/server you missed a important post of another person _ iOS 4.3 or later, and OS X 10.7 or later, fully support PIE executables; moreover, applications submitted for distribution via Apple's App Store are required to be fully position-independent In OpenBSD, the amd64 and other platforms have been switched to PIE (position-independent executables) by default _ I don't want to go the road where press articles say a specific bug in software XYZ available for Linux, BSD and OSX would have only on Fedora not been mitigated because we still discuss over performance impacts while others already went ahead https://fedoraproject.org/wiki/Foundations First represents our commitment to innovation I would welcome Fedora be first in things like this topic instead as often in the past replace already working things with unfinished alpha quality and need 3 follow-up releases to get back from where it came and praise new things which are in fact regression-fixes and features which where there before the replacements signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Fri, 9 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote: ... Microbenchmarks get us only so far, we need to know the impact the change makes for the whole system. We won't know that until enough packages have been rebuilt. https://www.alpinelinux.org/about/ The kernel is patched with grsecurity/PaX out of the box, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. The whole system performance can't be that bad. Other distributions (Alpine Linux being one of them) are already fully PIE enabled. Dhiru-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Fri, Jan 09, 2015 at 06:45:47PM +0100, Dhiru Kholia wrote: On Fri, 9 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote: ... Microbenchmarks get us only so far, we need to know the impact the change makes for the whole system. We won't know that until enough packages have been rebuilt. https://www.alpinelinux.org/about/ The kernel is patched with grsecurity/PaX out of the box, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. The whole system performance can't be that bad. Other distributions (Alpine Linux being one of them) are already fully PIE enabled. I think we're in agreement. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 09.01.2015 um 12:54 schrieb Jakub Jelinek: On i?86 it isn't around 10%, but more like 10%-30%. i doubt that it's always 30% - real workloads matter not worst cases and what are the 100% - if 100% is below a second 30% don't matter - there are millions of tasks where even 50% would not matter what you also ignore is that most tasks are already in DSO libraries and the executeable binaries itself are only a small part these days however, i686 is a dying architecture, otherwise RHEL would not have stopped tu support it at all and i personally did not see any i686 machine in the past 6 years That said, even on x86_64 it isn't anything close to no overhead. Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then rebuild stage3 of GCC with make -j1 separately with the original stage3 cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which included still time for various other tools being not PIE, make, ld, as) got 2.1% slower user time. Also, the number of relocations and memory consumption got up. Non-PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries: Relocation section '.rela.plt' at offset 0x188f00 contains 284 entries: GNU_RELRO 0x1d14730 0x02314730 0x02314730 0x0058d0 0x0058d0 R 0x1 PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d90 contains 75803 entries: Relocation section '.rela.plt' at offset 0x344018 contains 230 entries: GNU_RELRO 0x1e18cf0 0x02018cf0 0x02018cf0 0x10e310 0x10e310 R 0x1 That means e.g. on the startup of each cc1plus process, that means 1MB extra COW wastage (executable has 24KB of pages written and then made non-writable, while PIE over 1MB) that may all be true while 2% don't impress me that much *but* since *mobile phones* and other operating systems in the meantime are full PIE and it improves security how can someone justify the reason performance on a desktop/server distribution with much more powerful hardware? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Thu, Jan 08, 2015 at 01:45:20PM -0500, Miloslav Trmač wrote: Hello, = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” On i?86 it isn't around 10%, but more like 10%-30%. That said, even on x86_64 it isn't anything close to no overhead. Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then rebuild stage3 of GCC with make -j1 separately with the original stage3 cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which included still time for various other tools being not PIE, make, ld, as) got 2.1% slower user time. Also, the number of relocations and memory consumption got up. Non-PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries: Relocation section '.rela.plt' at offset 0x188f00 contains 284 entries: GNU_RELRO 0x1d14730 0x02314730 0x02314730 0x0058d0 0x0058d0 R 0x1 PIE cc1plus: Relocation section '.rela.dyn' at offset 0x187d90 contains 75803 entries: Relocation section '.rela.plt' at offset 0x344018 contains 230 entries: GNU_RELRO 0x1e18cf0 0x02018cf0 0x02018cf0 0x10e310 0x10e310 R 0x1 That means e.g. on the startup of each cc1plus process, that means 1MB extra COW wastage (executable has 24KB of pages written and then made non-writable, while PIE over 1MB). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Jan 2015 20:25:36 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2015 um 19:45 schrieb Miloslav Trmač: = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” probably not worth the worry, new machines are x86_64 mostly, keep in mind RHEL7 dropped i686 at all even if they are still used - 10% sounds much *but* such old machines mostly have a special task and are far away from noticeable load and it really depends on the workload if you even notice 20% performance drop at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. It would be interesting to see how performance was impacted on 32 bit arm The address space on 32 bit is relatively small so randomization does not gain much in terms of security anyway (you could bruteforce the addresses in a reasonable amount of time). So high cost low benefit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Jan 2015 20:25:36 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2015 um 19:45 schrieb Miloslav Trmač: = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” probably not worth the worry, new machines are x86_64 mostly, keep in mind RHEL7 dropped i686 at all even if they are still used - 10% sounds much *but* such old machines mostly have a special task and are far away from noticeable load and it really depends on the workload if you even notice 20% performance drop at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. It would be interesting to see how performance was impacted on 32 bit arm Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUrw/pAAoJEH7ltONmPFDRcmIQAIE+s6LNOA+Sj1nWnzzhRb+N e4Zf5DUAJl7N48taMiHgivVm9nQR1poOu99H1FMMPtskaoKFBgEEgBpSH3THXQSm c/PS6T6SeDn5BwO/9LIsmd/A+JtWlMBGl4N4HjSiLvMOu93YYlIoYUFjuln+ION0 GjMrMkIiKAGI5de7xmhohd/f82+69stANxqukkGhP4KJOq20PA075eKNvtNIwBqE kpTCueEBbpZtaYFRLC749flURRhyFKFJsqWiYa5SW6azq4xQOIOsQ8NJ7HazmA4z bwTkjGYzoE2NDD0+Cqb2hHbjuC3gZBEIqfF0b0eX9gRBHTfxw4VquBky/dKnjHMc UUHCNyMtnVDotfz5bGRekJGlkcynEmquzNz9sEhhB6cfhnr79I4eNRnjMeEzhkIo ysYbVh/iXJL5jdiRCC2AjBcVX0tOe/etUz7MLCDyWeh929iulkPVXUPhrN0fRLO5 RDz1Z2t7uE6RZGQ4JtzZvHcdgBAOSJSj2cxwdDtyvGwbDFxTQRmAoY+pmuL7Ny71 wxaMUkmODszSEsNxxp7TKU3+Q26Ju9jdA2AToFFdm9WqyJVQYO239414TXgQzDAM MMmM+YUKIDVGf/dwrEteyw4+ksF2C39r8KHSIx4jC/wbf84Ain91cNzUFTQow2RC JgR5QsmMIy593naNYzbv =+w+u -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Fri, Jan 9, 2015 at 12:44 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.01.2015 um 00:35 schrieb drago01: On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore den...@ausil.us wrote: On Thu, 08 Jan 2015 20:25:36 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2015 um 19:45 schrieb Miloslav Trmač: = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” probably not worth the worry, new machines are x86_64 mostly, keep in mind RHEL7 dropped i686 at all even if they are still used - 10% sounds much *but* such old machines mostly have a special task and are far away from noticeable load and it really depends on the workload if you even notice 20% performance drop at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. It would be interesting to see how performance was impacted on 32 bit arm The address space on 32 bit is relatively small so randomization does not gain much in terms of security anyway (you could bruteforce the addresses in a reasonable amount of time). So high cost low benefit don't ignore the maintainance costs for handle i686 different, That boils down to different compiler flags not a big deal in term of maintenance. take that into account (including bugreports with different build-flags) the benefit may be higher and the main question is still: how much is the *feelable and real* impact for the user in case of normal operations besides benchmarks 10% (number from the other mail) is a lot especially on machines that are slow anyway. On a fast machine you might not notice a few percent drop in general use (depends what you do though) but on a slow machine you would. Also slower code means the cpu is busy for a longer duration which means higher power consumption. As for 32bit ARM it is not register starved as x86 (32bit) is but I haven't seen any numbers on it yet. The limited size of the address space still applies there though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 09.01.2015 um 00:16 schrieb Dennis Gilmore: On Thu, 08 Jan 2015 20:25:36 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2015 um 19:45 schrieb Miloslav Trmač: = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” probably not worth the worry, new machines are x86_64 mostly, keep in mind RHEL7 dropped i686 at all even if they are still used - 10% sounds much *but* such old machines mostly have a special task and are far away from noticeable load and it really depends on the workload if you even notice 20% performance drop at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. that would be the main question and how large is the real impact besides syntetic benchmarks - thats partly the same as for how fast your machine boots - how often does it boot a day and the same for starting applications when consider caching a benchmark is nice to compare and get a picture but it practically never reflects the typical workload of a human (let us ignore FPS and games at that point) It would be interesting to see how performance was impacted on 32 bit arm given that this thread made clear most mobile operating systems enforce full PIE/PIC and most are running ARM on 32 bit i'd say if we have a much larger problem if that's a showstopper for Fedora however, numbers and *real human testing* would be interesting too signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 09.01.2015 um 00:35 schrieb drago01: On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore den...@ausil.us wrote: On Thu, 08 Jan 2015 20:25:36 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2015 um 19:45 schrieb Miloslav Trmač: = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” probably not worth the worry, new machines are x86_64 mostly, keep in mind RHEL7 dropped i686 at all even if they are still used - 10% sounds much *but* such old machines mostly have a special task and are far away from noticeable load and it really depends on the workload if you even notice 20% performance drop at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that userbase is in the millions, but would they notice the performance drop I do not know. It would be interesting to see how performance was impacted on 32 bit arm The address space on 32 bit is relatively small so randomization does not gain much in terms of security anyway (you could bruteforce the addresses in a reasonable amount of time). So high cost low benefit don't ignore the maintainance costs for handle i686 different, take that into account (including bugreports with different build-flags) the benefit may be higher and the main question is still: how much is the *feelable and real* impact for the user in case of normal operations besides benchmarks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, 7 Jan 2015, Till Maas wrote: On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? I proposed to make it the default for all archs and not only x86_64. From what I understand, the only reason it was not accepted is because it was felt that the performance penalty is not worth the security gains from this. I do not have objective numbers about how many exploits that happened could be prevented with PIE and how many effort it took to clean up after exploits compared to how much the performance penalty for PIE costs. However, the experts that I talked about this think the protection is worth it. I was also told that there were exploits where PIE helped to mitigate them. Nevertheless, nevertheless, thank you for the ticket link, it contains a lot of interesting information. However it is said that even though the packaging guidelines were mentioned there, they were kept in an unclear/contradictory state. But this is also a new data point, even though it was highlighted more 20 months ago to FeSCo, there are still a lot of packages violating the Guideline, which shows that the current process does not really work. And if PIE is not really considered to worth it, the guidelines should be adjusted to reflect this. Currently it does not seem to be the case that most/all packages that should be using PIE do not use it because maintainer actively decided against it, but just because it is not the default. The criteria for this is: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. ... Here are some more facts to support PIE (from https://github.com/kholia/PIE-stuff) iOS 4.3 or later, and OS X 10.7 or later, fully support PIE executables; moreover, applications submitted for distribution via Apple's App Store are required to be fully position-independent. Starting with Android 4.1, Google is forcing full ASLR (PIE) to overcome common security exploits. In OpenBSD, the amd64 and other platforms have been switched to PIE (position-independent executables) by default. Google Chrome and Opera binaries for Linux are already PIE. Firefox folks are already looking at support and / or enabling PIE. Isn't browser the place where your primary computation (aka FB) now happens? ;) The original GitHub repository should have more information, references, and some tools. In short, PIE is compulsorily required on mobile phones, which are limited CPU and battery wise. If the mobile vendors can afford to enable PIE (by default) on their consumer-grade products, I believe that we can do a bit better (on AMD64 servers). I am currently lacking free time (and energy) to drive the original FESCo proposal forward. It's awesome to see other folks driving this now. Thanks guys! Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Thu, 8 Jan 2015, Dhiru Kholia wrote: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. Can we throw prelink out as well when we do this? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Thu, 2015-01-08 at 08:47 -0500, Paul Wouters wrote: On Thu, 8 Jan 2015, Dhiru Kholia wrote: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. +1. This view is rapidly gaining traction and visibility in recent times. Can we throw prelink out as well when we do this? Prelink is already gone. We haven't been running it since F19, IIRC. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Thu, 8 Jan 2015, Stephen Gallagher wrote: Can we throw prelink out as well when we do this? Prelink is already gone. We haven't been running it since F19, IIRC. Oh. Spending too much time on RHEL, and not enough time to upgrade my desktop to a non-EOL fedora :) Thanks, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Hello, = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 08.01.2015 um 19:45 schrieb Miloslav Trmač: = Proposed System Wide Change: Harden all packages with position-independent code = Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. So this proposal is for _all_ architectures, including the register-starved 32-bit i?86 where the overhead is, IIRC, around 10%. I am by now quite convinced that x86_64 should be using PIE by default. As for 32-bit, I’m torn between “this is too much overhead” and “32-bit isn’t worth the worry, let’s instead make the defaults consistent.” probably not worth the worry, new machines are x86_64 mostly, keep in mind RHEL7 dropped i686 at all even if they are still used - 10% sounds much *but* such old machines mostly have a special task and are far away from noticeable load and it really depends on the workload if you even notice 20% performance drop at least i doubt there is a noticeable userbase with i686 running Fedora at all *and* would notice the drop noticeable signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F22 System Wide Change: Harden all packages with position-independent code
= Proposed System Wide Change: Harden all packages with position-independent code = https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code Change owner(s): Till Maas opensou...@till.name, Moez Roy moez@gmail.com Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. == Detailed Description == Currently, the Packaging Guidelines allow maintainers to decide whether their packages use position-independent code (PIC). There are rules that say that a lot of packages should use PIC, but in reality a lot of packages do not use PIC even if they must. Also since a lot of packages if not all potentially process untrusted input, it makes sense for these packages to use PIC to enhance the security of Fedora. Therefore I propose to build all packages with PIC by changing RPM to use the appropriate flags by default. References: * https://fedorahosted.org/rel-eng/ticket/6049 * There should be several mails about this on the devel list == Scope == * Proposal owners: Help writing the new packaging guidelines. * Other developers: Change the rpm macros to build packages by default with PIC/PIE flags (i.e. set _hardened_package to 1 by default). * Release engineering: Do a mass rebuild for all arch packages * Policies and guidelines: Adjust the Packaging Guidelines to allow non-PIC packages only if the package is not working otherwise and require a tracker bug similar to packages not working on certain archs. Update the Guidelines to reflect the new defaults. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, Jan 7, 2015 at 5:30 AM, Josh Boyer jwbo...@fedoraproject.org wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Hi Josh, That ticket is over 20 months old. It was discussed at time when Fedora 19 was in beta stage. I believe alot has changed since then. Since Fedora 20 pre-link is already disabled by default. The security landscape has changed. With the major publicity from Heartbleed and ShellShock, I believe more people are now security conscious than before. Hopefully, they will understand the need for compromise in system performance in order to protect the system from being exploited. For example: here http://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html (CVE-2014-8485) it states Many Linux distributions ship *strings* without ASLR, making potential attacks easier and more reliable - a situation reminiscent of one of the recent bugs in *bash*. Which links here: http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html (CVE-2014-6277) and (CVE-2014-6278) and states The issue is also made worse by the fact that only relatively few distributions were building bash as a position-independent executable that could be fully protected by ASLR. -Moez -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
I originally made a request to rel-eng here: https://fedorahosted.org/rel-eng/ticket/6049 - Long running packages in F21 that 'MUST enable the PIE compiler flags' Here https://fedoraproject.org/wiki/Packaging:Guidelines#PIE it says If your package meets any of the following criteria you MUST enable the PIE compiler flags: Your package is long running. This means it's likely to be started and kept running until the machine is rebooted... [root@localhost liveuser]# checksec --proc-all | grep No PIE Xorg.bin 1037 Partial RELRO Canary found NX enabledNo PIE gnome-session 1227 Partial RELRO Canary found NX enabledNo PIE at-spi-bus-laun 1300 Partial RELRO Canary found NX enabledNo PIE at-spi2-registr 1308 Partial RELRO Canary found NX enabledNo PIE gvfsd 1318 Partial RELRO Canary found NX enabledNo PIE gvfsd-fuse 1322 Partial RELRO Canary found NX enabledNo PIE gnome-settings- 1339 Partial RELRO Canary found NX enabledNo PIE gnome-keyring-d 1344 Partial RELRO Canary found NX enabledNo PIE gnome-shell 1455 Partial RELRO Canary found NX enabledNo PIE gsd-printer 1486 Partial RELRO Canary found NX enabledNo PIE dconf-service 1504 Partial RELRO Canary found NX enabledNo PIE gnome-shell-cal 1514 Partial RELRO Canary found NX enabledNo PIE evolution-sourc 1520 Partial RELRO Canary found NX enabledNo PIE goa-daemon 1526 Partial RELRO Canary found NX enabledNo PIE ibus-daemon 1530 Partial RELRO Canary found NX enabledNo PIE mission-control 1534 Partial RELRO Canary found NX enabledNo PIE ibus-dconf 1541 Partial RELRO Canary found NX enabledNo PIE ibus-x11 1543 Partial RELRO Canary found NX enabledNo PIE caribou 1571 Partial RELRO Canary found NX enabledNo PIE gvfs-udisks2-vo 1586 Partial RELRO Canary found NX enabledNo PIE gvfs-afc-volume 1594 Partial RELRO Canary found NX enabledNo PIE gvfs-mtp-volume 1600 Partial RELRO Canary found NX enabledNo PIE gvfs-gphoto2-vo 1605 Partial RELRO Canary found NX enabledNo PIE gvfs-goa-volume 1610 Partial RELRO Canary found NX enabledNo PIE evolution-alarm 1662 Partial RELRO Canary found NX enabledNo PIE tracker-miner-a 1665 Partial RELRO Canary found NX enabledNo PIE tracker-store 1670 Partial RELRO Canary found NX enabledNo PIE seapplet 1671 Partial RELRO Canary found NX enabledNo PIE tracker-extract 1676 Partial RELRO Canary found NX enabledNo PIE tracker-miner-u 1680 Partial RELRO Canary found NX enabledNo PIE gnome-software 1681 Partial RELRO Canary found NX enabledNo PIE tracker-miner-f 1683 Partial RELRO Canary found NX enabledNo PIE evolution-calen 1710 Partial RELRO Canary found NX enabledNo PIE ibus-engine-sim 1740 Partial RELRO No canary foundNX enabledNo PIE gnome-terminal- 1870 Partial RELRO Canary found NX enabledNo PIE gconfd-2 1876 Partial RELRO Canary found NX enabledNo PIE bash 1879 Partial RELRO Canary found NX enabledNo PIE bash 1910 Partial RELRO Canary found NX enabledNo PIE firefox 5931 Partial RELRO Canary found NX enabledNo PIE gvfsd-metadata 6054 Partial RELRO Canary found NX enabledNo PIE oosplash 6140 Partial RELRO Canary found NX enabledNo PIE gvfsd-burn 6166 Partial RELRO Canary found NX enabledNo PIE soffice.bin 6227 Partial RELRO No canary foundNX enabledNo PIE evince 6278 Partial RELRO Canary found NX enabledNo PIE gvfsd-trash 6296 Partial RELRO Canary found NX enabledNo PIE nautilus 6319 Partial RELRO Canary found NX enabledNo PIE bash 6339 Partial RELRO Canary found NX enabledNo PIE python 6366 Partial RELRO No canary foundNX enabledNo PIE sedispatch678 Partial RELRO Canary found NX enabledNo PIE firewalld722 Partial RELRO No canary foundNX enabledNo PIE mcelog728 Partial RELRO Canary found NX enabledNo PIE grep 8620 Partial RELRO Canary found NX enabledNo PIE [root@localhost
Re: F22 System Wide Change: Harden all packages with position-independent code
Am 07.01.2015 um 23:04 schrieb Till Maas: On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? I proposed to make it the default for all archs and not only x86_64. From what I understand, the only reason it was not accepted is because it was felt that the performance penalty is not worth the security gains from this. I do not have objective numbers about how many exploits that happened could be prevented with PIE and how many effort it took to clean up after exploits compared to how much the performance penalty for PIE costs. in doubt a successful exploit does that much damage that you no longer bother about some percent of performance and i really don't understand all that performance discussions i built *all* server packages running on our Fedora machines *long before* -fstack-protector-strong became available with -fstack-protector-all and i really care about every piece of performance but not for the price of lower security yes i maintain all my apache, postfix, dovecot, mysql, php and what not packages in a own repo with maximized security options for 7 years now and any tool not in the Fedora repos get a hardened build too *but* i do not care about 5% performance because the time, money and reputation impact caused by a successful exploit destroying and leaking user data justifies to protect with all available technology and in doubt if you need the 5% performance it justifies just go out and buy a faster machine yes, i talk about servers - because on a workstation it *really* don't matter if LibreOffice the first time of a day starts a second longer except for beenchmarking as digital p*** enlargement However, the experts that I talked about this think the protection is worth it. I was also told that there were exploits where PIE helped to mitigate them. i asked after Shellshock and reading that one of the issues would have been mitigated on teh security list and referred to the 20 month old tickt Nevertheless, nevertheless, thank you for the ticket link, it contains a lot of interesting information. However it is said that even though the packaging guidelines were mentioned there, they were kept in an unclear/contradictory state. But this is also a new data point, even though it was highlighted more 20 months ago to FeSCo, there are still a lot of packages violating the Guideline i filed *countless* bugreports for packages violating this in the past 2 years, many of them got fixed in the meantime the main problem is long running - look how many prcoesses are started on a ordinary desktop setup on-demand and than run forever and you get a picture frankly, even the browser, mailprogramm, messenger and so on are in fact *long running* even if they are not servcices because most users start them and have them running until logout, often over days and guess what - all of this apps are processing untrsuted data from the network, at the end of the day LibreOffice does too - just open a attachment from a email and hit a unfixed security bug which shows that the current process does not really work. And if PIE is not really considered to worth it, the guidelines should be adjusted to reflect this. Currently it does not seem to be the case that most/all packages that should be using PIE do not use it because maintainer actively decided against it, but just because it is not the default. The criteria for this is: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet that's the point - in doubt even cat/grep prcoeed untrusted input from the web by watch a simple logfile, there where even exploits http://httpd.apache.org/security/vulnerabilities_22.html mod_rewrite does not filter terminal escape sequences from logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences. *every* application at the end of the day is at risk to proceed untrsuted input from the web - and if it is only because it has to deal with some download from the internt, in that context it don't matter if it is long running or not signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, 7 Jan 2015 13:17:36 -0800 Moez Roy moez@gmail.com wrote: I originally made a request to rel-eng here: https://fedorahosted.org/rel-eng/ticket/6049 - Long running packages in F21 that 'MUST enable the PIE compiler flags' ...snip... The above packages don't seem to have PIE enabled. Some of them don't meet the 'long running' critera. They just happen to be running when you ran your check. Can someone from releng enable hardening on as many Long running packages as possible before the next F21 Release Candidate. No. This is not a releng task. This is something that should be done by (in order): - The maintainers of these packages. - Interested/motivated provenpackagers who want to make the changes and bring the packages in line with guidelines. - Some other group FESCo is able to task with it (which really might come down to just them). But since this change is for just globally enabling it, probibly the best thing to do is wait for this change to be accepted and a mass rebuild instead of worrying now about specific packages. kevin pgpfuD7sMWzn5.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote: We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? I proposed to make it the default for all archs and not only x86_64. From what I understand, the only reason it was not accepted is because it was felt that the performance penalty is not worth the security gains from this. I do not have objective numbers about how many exploits that happened could be prevented with PIE and how many effort it took to clean up after exploits compared to how much the performance penalty for PIE costs. However, the experts that I talked about this think the protection is worth it. I was also told that there were exploits where PIE helped to mitigate them. Nevertheless, nevertheless, thank you for the ticket link, it contains a lot of interesting information. However it is said that even though the packaging guidelines were mentioned there, they were kept in an unclear/contradictory state. But this is also a new data point, even though it was highlighted more 20 months ago to FeSCo, there are still a lot of packages violating the Guideline, which shows that the current process does not really work. And if PIE is not really considered to worth it, the guidelines should be adjusted to reflect this. Currently it does not seem to be the case that most/all packages that should be using PIE do not use it because maintainer actively decided against it, but just because it is not the default. The criteria for this is: | Your package accepts/processes untrusted input. This seems to be about every package that I use, because I most if not all tools process untrusted data from the Internet. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Harden all packages with position-independent code
On Wed, Jan 7, 2015 at 6:41 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Harden all packages with position-independent code = https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code Change owner(s): Till Maas opensou...@till.name, Moez Roy moez@gmail.com Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. == Detailed Description == Currently, the Packaging Guidelines allow maintainers to decide whether their packages use position-independent code (PIC). There are rules that say that a lot of packages should use PIC, but in reality a lot of packages do not use PIC even if they must. Also since a lot of packages if not all potentially process untrusted input, it makes sense for these packages to use PIC to enhance the security of Fedora. Therefore I propose to build all packages with PIC by changing RPM to use the appropriate flags by default. References: * https://fedorahosted.org/rel-eng/ticket/6049 * There should be several mails about this on the devel list We just went over something very much like this for x86_64 packages with FESCo ticket 1113: https://fedorahosted.org/fesco/ticket/1113 Could you perhaps review that and elaborate on the differences between that proposal and this one if there are any? Additionally, could you cover any of the concerns listed there that apply to this proposal? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
