Consistency of PIE has come up a couple of times and it seems upstream gcc added the --enable-default-pie to gcc-6 to ensure this[1] so it would be useful to ensure this is enabled in Fedora to ensure enforcement of hardened builds. Debian did see a problem when enabling this [2] with kernel builds but fix should now be upstream in the kernel. [1] https://gcc.gnu.org/gcc-6/changes.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841420
I agree that the way we currently inject build flags is a major usability issue compared to Debian. However, we should do this as a system-wide change for all hardening flags (stack protector, full RELRO, PIE, source fortification, stack checking) at the same time. This is clearly a system-wide change, and it's too late for that for Fedora 27.
Completely agreed, I meant to file this some time ago and it got lost in the ToDo list. Would be useful to have this land in f28/rawhide as soon as F-27 branches which is due to be Aug 15th according to the schedule [1] [1] https://fedoraproject.org/wiki/Releases/27/Schedule
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Moving this to rawhide as f28 will be the next possible mass rebuild
Can we ensure this is done for F-28?
I discussed this with our gcc maintainters. Most of them are not in favor of this change because they think that altering default gcc behavior in this way is a bad idea. (There is actually fairly strong opposition.) Is this about building more packages in Fedora with PIE, or do you specifically need the GCC default change? If it is about the former: I'm working on measuring build hardening in Fedora via annobin. https://fedoraproject.org/wiki/Changes/Annobin I do not think --enable-default-pie would make a significant difference as far as the completeness of build hardening goes. If a packages misses -Wl,-pie, the proposed change adds it, but it will likely lack -Wl,-z,now even after this change, so manual intervention at the packaging level would still be needed to implement the Fedora compiler policy.
(In reply to Florian Weimer from comment #7) > I discussed this with our gcc maintainters. Most of them are not in favor > of this change because they think that altering default gcc behavior in this > way is a bad idea. (There is actually fairly strong opposition.) Is there any reasons the technical opposition of this be documented in the ticket? > Is this about building more packages in Fedora with PIE, or do you > specifically need the GCC default change? There's a number of distributions that have this option, such as Debian, there's been a number of issue with libraries cause issues over the years with libraries overriding CFLAGs and there not being PIE in libraries (which from experience can cause FTBFS and other issues). It's my understanding that this deals with that and that's why Debian went with it. > If it is about the former: I'm working on measuring build hardening in > Fedora via annobin. How is that fixed? Ongoing manual intervention with every single package with each change/failure moving forward? > https://fedoraproject.org/wiki/Changes/Annobin > > I do not think --enable-default-pie would make a significant difference as > far as the completeness of build hardening goes. If a packages misses > -Wl,-pie, the proposed change adds it, but it will likely lack -Wl,-z,now > even after this change, so manual intervention at the packaging level would > still be needed to implement the Fedora compiler policy. Right, but that doesn't explain why there's "fairly strong opposition"
The --enable-default-pie is a dirty hack used by lazy people to workaround proper maintainance of packages, which really should honor the flags given from the package managers except when there is a strong reason not to. Making say -pie -fpie the default is similar to changing the default for -O0 to -O2, it changes the behavior of the toolchain in very significant way and people that don't want those changes then need to play dirty games to undo all those changes enforced upon them, see the kernel being full of -fno-this -fno-that because some distros decided to change the defaults of this and that. A PIE by default is a questionable change even for the whole distribution (rather than selected subset), and is even more questionable to many users that just want a performant app they compile themselves which won't run with elevated priviledges or otherwise be exposed to external threats. It would degrade by tens of % benchmark performance, unless the user plays the same game as the kernel and keeps adding -fno-this -fno-that stuff every release when the defaults change. So, I strongly oppose not just to change the -O0 default to -O2, but also make PIE the default, or force -fstack-clash-protection or -fstack-protector or -D_FORTIFY_SOURCE* by default in the compiler rather than in redhat-rpm-config. There are many other useful flags propagated from those flags like tuning decisions etc. that need to be honored anyway. Let's just fix packages that don't honor the flags without a reason, and annobin is a useful tool for that.
(In reply to Peter Robinson from comment #8) > (In reply to Florian Weimer from comment #7) > > I discussed this with our gcc maintainters. Most of them are not in favor > > of this change because they think that altering default gcc behavior in this > > way is a bad idea. (There is actually fairly strong opposition.) > > Is there any reasons the technical opposition of this be documented in the > ticket? See Jakub's reply. > > Is this about building more packages in Fedora with PIE, or do you > > specifically need the GCC default change? > > There's a number of distributions that have this option, such as Debian, > there's been a number of issue with libraries cause issues over the years > with libraries overriding CFLAGs and there not being PIE in libraries (which > from experience can cause FTBFS and other issues). It's my understanding > that this deals with that and that's why Debian went with it. Debian pretty much mandates static libraries for C/C++ libraries, so its needs are very different from Fedora, where the PIE-less .a archive can only affect extremely few packages. Furthermore, the GCC specfile approach we use ensures correct flags for both static and shared builds, so it does not suffer from the problems of some other early flag injection approaches others have tried. So I'm still not convinced that PIE is different from other hardening flags (except that there is a --enable-default-pie switch). > > If it is about the former: I'm working on measuring build hardening in > > Fedora via annobin. > > How is that fixed? Ongoing manual intervention with every single package > with each change/failure moving forward? That depends on what we see in the data. So far, a lot of the packages without the default hardening coverage built with alternative toolchains. It may be the case that the remaining C/C++ outliers can just be fixed manually. If not, we need a different solution for the buildroot, but that is a separate discussion. “gcc” in the buildroot (at the start of the %build section) does not necessarily have to refer to /usr/bin/gcc, after all.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.