Re: [arch-dev-public] CFLAGS
On 28/07/15 05:42, Jan Alexander Steffens wrote: On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae al...@archlinux.org wrote: We have a couple of bugs open about our CFLAGS. 1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed. 2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though. This would mean: CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check Opinions? Seems sound given our focus on IA32 (don't know about other architectures). +1 from me. Any other comments before I rebuild pacman with these changes? Allan
Re: [arch-dev-public] CFLAGS
On 27/07, Jan Alexander Steffens wrote: On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae al...@archlinux.org wrote: We have a couple of bugs open about our CFLAGS. 1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed. 2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though. This would mean: CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check Opinions? Seems sound given our focus on IA32 (don't know about other architectures). +1 from me. Our focus on IA32? -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/ signature.asc Description: PGP signature
Re: [arch-dev-public] CFLAGS
-fstack-check works very well on x86 and x86_64 but is quite buggy on other architectures like ARM. I'm not quite sure if that was the point being made though. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] CFLAGS
On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae al...@archlinux.org wrote: We have a couple of bugs open about our CFLAGS. 1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed. 2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though. This would mean: CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check Opinions? Seems sound given our focus on IA32 (don't know about other architectures). +1 from me.
[arch-dev-public] CFLAGS
We have a couple of bugs open about our CFLAGS. 1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed. 2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though. This would mean: CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check Opinions? Allan
[arch-dev-public] CFLAGS changes with gcc-4.9
Hi all, gcc-4.9 is due to be released on the 22nd. This brings a new stack protection flag, -fstack-protector-strong. See this blog post for some details [1]. I would like to do two things with the release of gcc-4.9: 1) Add -fstack-protector-strong to our CFLAGS 2) Rebuild all [core] packages The rebuild would not only add the extra stack protection, but also ensure all [core] packages have .MTREE files (which become more useful with the next pacman release, although still do not test checksums). Any opinions on both of these points? Cheers, Allan [1] http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
Re: [arch-dev-public] CFLAGS changes with gcc-4.9
Am 12.04.2014 09:22, schrieb Allan McRae: Hi all, gcc-4.9 is due to be released on the 22nd. This brings a new stack protection flag, -fstack-protector-strong. See this blog post for some details [1]. I would like to do two things with the release of gcc-4.9: 1) Add -fstack-protector-strong to our CFLAGS 2) Rebuild all [core] packages The rebuild would not only add the extra stack protection, but also ensure all [core] packages have .MTREE files (which become more useful with the next pacman release, although still do not test checksums). Don't they already have them? Any opinions on both of these points? The kernel also has a new option CONFIG_CC_STACKPROTECTOR_STRONG in 3.14. Obviously, this is currently disabled in our build. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] CFLAGS changes with gcc-4.9
On 12/04/14 17:52, Thomas Bächler wrote: Am 12.04.2014 09:22, schrieb Allan McRae: Hi all, gcc-4.9 is due to be released on the 22nd. This brings a new stack protection flag, -fstack-protector-strong. See this blog post for some details [1]. I would like to do two things with the release of gcc-4.9: 1) Add -fstack-protector-strong to our CFLAGS 2) Rebuild all [core] packages The rebuild would not only add the extra stack protection, but also ensure all [core] packages have .MTREE files (which become more useful with the next pacman release, although still do not test checksums). Don't they already have them? .MTREE files were introduced with pacman-4.1 on 2013-04-01. There appears to be a few packages without them still: https://www.archlinux.org/packages/?repo=Coresort=last_update Any opinions on both of these points? The kernel also has a new option CONFIG_CC_STACKPROTECTOR_STRONG in 3.14. Obviously, this is currently disabled in our build.
