Replace the current _FORTIFY_SOURCE=2 with _FORTIFY_SOURCE=3 to improve mitigation of security issues arising from buffer overflows in packages in Fedora.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
I'm not happy with the double standard that is implicit with this change proposal.
-1
I'm not happy with the double standard that is implicit with this change proposal. -1
Please note the performance update in the wiki page. Vladimir Makarov from my team ran SPEC2000 and SPEC2017 and found no difference in performance between _FORTIFY_SOURCE=2 and _FORTIFY_SOURCE=3. In fact, some tests in SPEC2000 ran slightly faster with _FORTIFY_SOURCE=3, which I'd love to study in future since it goes against what I had hypothesized.
That should reduce the performance risk considerably to corner cases as I had thought of originally, which should be handled on a per-package basis.
Ok, I'm going to attempt some nuance here - not sure if I'll succeed, but I'll try. The part that is off-topic for this ticket is below the fold. :)
Looking at the data provided in the spreadsheet for this change, binary size changed by ±0.00% (!) on average, so that doesn't look bad at all. Performance impact is apparently also a wash, with some workloads slightly regressing, but others slightly improving - so that doesn't look bad, either. But it sounds like the better security hardening is, in fact, very worthwhile. As I see it, this change would be a net positive for Fedora, so I am inclined to vote +1 here.
However, there's been another change proposal about changing default compiler flags ... which I would like us to re-consider. In hindsight, I think the bar we set for the frame pointer change was way too high, and the way it was rejected in the FESCo meeting a few weeks ago was also kind of "abrupt" - with just a general "yes or no" question, and no possibility for considering alternative approaches, or something like a conditional / temporary approval with evaluation after one release cycle.
Given that alternatives to frame-pointer based unwinding don't (really) exist (yet?) or are not feasible for "real-time profiling" (if I understand things correctly), this seems to be the "only" solution that works "most of the time, right now", with other solutions being in the "this might work at some point in the future, or it might not work at all" stage.
Additionally, some software we ship / advertise is, if I understand correctly, already compiled with this configuration - like the freedesktop flatpak runtime, and presumably also the gnome flatpak runtimes, and most flatpak apps built in top of these runtimes, unless they specifically opt out.
Assuming the Change authors still want this change to land - what would be the procedure for reconsidering a previously rejected change proposal?
I don't know if we've done it in the same cycle before, but I suppose we could just make a new ticket to reconsider it like what was done in #2905.
The Change authors still very much want this change to land.
I said my piece in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GD3OOE3ZQOUIAPFWP6VOJKVP5DZKI35S/, so I'll not repeat it here.
+1 to this change.
and no possibility for considering alternative approaches, or something like a conditional / temporary approval with evaluation after one release cycle.
I explicitly made such a proposal, and it was acked by Daan, but it didn't find much (any?) support in FESCo.
what would be the procedure for reconsidering a previously rejected change proposal?
No special procedure is needed. We can open a new ticket or reopen the old one. I think we should do this.
Yeah, I think this is very important. Other solutions (no matter whether feasible or not), are not going to appear any time soon. So for now we can either have profiling with this, or not.
I supported it, fwiw.
On the merits of this Change, I'm +1.
I said my piece in the first comment because I do truly believe we unfairly handled #2817. I'm perfectly happy having a new ticket open to vote on @zbyszek's proposal for #2817.
+1
The current vote is +3,0,0, but given the calendar and some of the concerns raised about this, I will hold off on processing the vote until after the new year.
Based on discussion and on the “Performance note”, it seems like this is unlikely to cause serious and widespread performance regressions. I have no other concerns with the proposal, and I’m happy to see improved defenses against this class of exploits, so:
We're at +5, and 19 days and one year have passed, so let's mark this as accepted.
APPROVED: +5, 0, 0
Metadata Update from @zbyszek: - Issue tagged with: pending announcement
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RNJZUX3ZI34DIX6E4PVDKYQWCOFDQ4UY/
Metadata Update from @churchyard: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.