< Changes
(→Scope) |
|||
| Line 72: | Line 72: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
Post a merge request to redhat-rpm-config with the actual change to build flags. | |||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
Resolve bugs filed for build failures, either by fixing the bug exposed by `_FORTIFY_SOURCE=3` or by disabling `_FORTIFY_SOURCE=3` for the package if it is a false positive or if the package is unable to adapt to the change. | |||
* Release engineering: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. | ||
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.--> | Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.--> | ||
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: | ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Mass rebuild required | ||
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | <!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | ||
* Policies and guidelines: None <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Policies and guidelines: None <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | ||
Guidelines should include workaround for packages that fail to build with `-Wp,-D_FORTIFY_SOURCE=3` due to a false positive. | |||
* Trademark approval: N/A (not needed for this Change) | * Trademark approval: N/A (not needed for this Change) | ||
Revision as of 15:44, 5 December 2022
Add _FORTIFY_SOURCE=3 to distribution build flags
Summary
Replace the current _FORTIFY_SOURCE=2 with _FORTIFY_SOURCE=3 to improve mitigation of security issues arising from buffer overflows in packages in Fedora.
Owner
- Name: Siddhesh Poyarekar
- Email: sipoyare@redhat.com, siddhesh@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 38
- Last updated: 2022-12-05
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
Default C and C++ compiler flags to build packages in Fedora currently includes -Wp,-D_FORTIFY_SOURCE=2, which enables fortification of some functions in glibc, thus providing some mitigation against buffer overflows. Since glibc 2.34 and GCC 12, there has been a new fortification level (_FORTIFY_SOURCE=3) which improves the coverage of this mitigation. Analysis of packages in Fedora rawhide indicate that the improvement of mitigation coverage is on average over 2.4x, in some cases protecting more than half of the fortified glibc calls in the target application.
The core change to bring in this mitigation is to change the default build flags in redhat-rpm-config so that packages build by default with -Wp,-D_FORTIFY_SOURCE=3.
Benefit to Fedora
This change will harden Fedora to a significant extent, thus making it a more secure distribution out of the box.
Scope
- Proposal owners:
Post a merge request to redhat-rpm-config with the actual change to build flags.
- Other developers:
Resolve bugs filed for build failures, either by fixing the bug exposed by _FORTIFY_SOURCE=3 or by disabling _FORTIFY_SOURCE=3 for the package if it is a false positive or if the package is unable to adapt to the change.
- Release engineering:
- List of deliverables: Mass rebuild required
- Policies and guidelines: None
Guidelines should include workaround for packages that fail to build with -Wp,-D_FORTIFY_SOURCE=3 due to a false positive.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
No ABI change, so there should be no impact on compatibility in a mixed environment.
How To Test
- fortify-metrics to get compiler level metrics of coverage improvement - Smoke testing of packages to ensure that they continue to work correctly. Some packages may have overflows exposed at runtime, which may need to be fixed.
User Experience
No noticeable change to users.
Dependencies
None.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
TODO