(→Scope) |
(Add trackers) |
||
(8 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
= Add _FORTIFY_SOURCE=3 to distribution build flags <!-- The name of your change proposal --> = | = Add _FORTIFY_SOURCE=3 to distribution build flags <!-- The name of your change proposal --> = | ||
== Summary == | == Summary == | ||
Line 14: | Line 12: | ||
* Name: [[User:siddhesh| Siddhesh Poyarekar]] | * Name: [[User:siddhesh| Siddhesh Poyarekar]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: sipoyare@redhat.com | * Email: siddhesh@redhat.com | ||
* Bugzilla email: sipoyare@redhat.com | |||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAcceptedF38]] | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
Line 32: | Line 30: | ||
--> | --> | ||
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NPR6CT7HEUBFJZJNGDBXKFLSMPE7UR5W/ devel thread] | * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NPR6CT7HEUBFJZJNGDBXKFLSMPE7UR5W/ devel thread] | ||
* FESCo issue: | * FESCo issue: [https://pagure.io/fesco/issue/2917 #2917] | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2158232 #2158232] | ||
* Release notes issue: | * Release notes issue: [https://pagure.io/fedora-docs/release-notes/issue/942 #942] | ||
== Detailed Description == | == Detailed Description == | ||
Line 91: | Line 89: | ||
--> | --> | ||
* | * Nearly 10,000 source packages were [https://copr.fedorainfracloud.org/coprs/siddhesh/mpb.49/ built in copr] with this flag using the mass prebuilder (and subsequently by hand to rule out transient issues) and failures reported, list is maintained in the [https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing spreadsheet]. Only package failure in the core OS is systemd and it has already been [https://github.com/systemd/systemd/issues/22801 reported upstream]. Systemd will have to be built without fortification until that issue is resolved. | ||
* Package maintainers should smoke test their packages after rebuild to ensure that no new bugs are found. Some packages may have overflows exposed at runtime, which may need to be fixed. | |||
== User Experience == | == User Experience == | ||
Line 100: | Line 99: | ||
=== Performance note === | === Performance note === | ||
Given that `_FORTIFY_SOURCE=3` generates size expressions instead of constants as in `_FORTIFY_SOURCE=2` and also succeeds in fortification in more cases than `_FORTIFY_SOURCE=2`, there is a theoretical concern of a performance overhead due to this. | Given that `_FORTIFY_SOURCE=3` generates size expressions instead of constants as in `_FORTIFY_SOURCE=2` and also succeeds in fortification in more cases than `_FORTIFY_SOURCE=2`, there is a theoretical concern of a performance overhead due to this. Tests using SPEC2000 and SPEC2017 show no real difference between `_FORTIFY_SOURCE=3` and `_FORTIFY_SOURCE=2`, which indicates that there is no general slowdown due to this feature. Hence this concern is limited to cases where the fortified function is in the hot path and at the same time, the size expression needs to be evaluated separately in each iteration of the hot path. Per-application performance benchmarks may be useful in understanding the impact for those specific use cases. | ||
In practice, no performance issues have been reported in distributions that have already enabled `_FORTIFY_SOURCE=3` by default. The linux kernel will [https://lore.kernel.org/linux-hardening/20220920192202.190793-1-keescook@chromium.org/T/#m5c6f5d590b7844d7a252f3e123af4d03f8dced87 improve its fortification] to match `_FORTIFY_SOURCE=3` by default in a future release. | In practice, no performance issues have been reported in distributions that have already enabled `_FORTIFY_SOURCE=3` by default. The linux kernel will [https://lore.kernel.org/linux-hardening/20220920192202.190793-1-keescook@chromium.org/T/#m5c6f5d590b7844d7a252f3e123af4d03f8dced87 improve its fortification] to match `_FORTIFY_SOURCE=3` by default in a future release. | ||
Line 115: | Line 112: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: (What to do? Who will do it?) If too many packages are found to be broken at runtime, the default for fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38. Change owner will do this in `redhat-rpm-config` | * Contingency mechanism: (What to do? Who will do it?) Packages that fail to work correctly with `_FORTIFY_SOURCE=3`, either due to bugs that are not immediately resolvable in the package or due to bug in the compiler or runtime will be fixed up to continue using `_FORTIFY_SOURCE=2`. If too many packages are found to be broken at runtime, the default for fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38. Change owner will do this in `redhat-rpm-config` | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: Beta freeze | * Contingency deadline: 2023-02-07 to decide if the default should be `_FORTIFY_SOURCE=2` or not. Beta freeze to switch packages with unresolved bugs related to this, to use `_FORTIFY_SOURCE=2`. | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? Yes <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Blocks release? Yes <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> |
Latest revision as of 18:09, 4 January 2023
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: siddhesh@redhat.com
- Bugzilla email: sipoyare@redhat.com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2023-01-04
- devel thread
- FESCo issue: #2917
- Tracker bug: #2158232
- Release notes issue: #942
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.
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
. There are packages (e.g. systemd
) that do not interact well with _FORTIFY_SOURCE
and will also need a workaround to downgrade fortification to level 2. The change will also include this override.
Benefit to Fedora
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.
This change will thus harden Fedora to a significant extent, thus making it a more secure distribution out of the box.
Status in other distributions
- All packages in OpenSUSE ALP are built with _FORTIFY_SOURCE=3 by default.
- Gentoo is considering making
_FORTIFY_SOURCE=3
the default level for theirhardened
profile
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: Mass rebuild required, ticket here: https://pagure.io/releng/issue/11173
- Policies and guidelines: 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
- Nearly 10,000 source packages were built in copr with this flag using the mass prebuilder (and subsequently by hand to rule out transient issues) and failures reported, list is maintained in the spreadsheet. Only package failure in the core OS is systemd and it has already been reported upstream. Systemd will have to be built without fortification until that issue is resolved.
- Package maintainers should smoke test their packages after rebuild to ensure that no new bugs are found. Some packages may have overflows exposed at runtime, which may need to be fixed.
User Experience
No user-visible functional change.
Performance note
Given that _FORTIFY_SOURCE=3
generates size expressions instead of constants as in _FORTIFY_SOURCE=2
and also succeeds in fortification in more cases than _FORTIFY_SOURCE=2
, there is a theoretical concern of a performance overhead due to this. Tests using SPEC2000 and SPEC2017 show no real difference between _FORTIFY_SOURCE=3
and _FORTIFY_SOURCE=2
, which indicates that there is no general slowdown due to this feature. Hence this concern is limited to cases where the fortified function is in the hot path and at the same time, the size expression needs to be evaluated separately in each iteration of the hot path. Per-application performance benchmarks may be useful in understanding the impact for those specific use cases.
In practice, no performance issues have been reported in distributions that have already enabled _FORTIFY_SOURCE=3
by default. The linux kernel will improve its fortification to match _FORTIFY_SOURCE=3
by default in a future release.
Dependencies
None.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) Packages that fail to work correctly with
_FORTIFY_SOURCE=3
, either due to bugs that are not immediately resolvable in the package or due to bug in the compiler or runtime will be fixed up to continue using_FORTIFY_SOURCE=2
. If too many packages are found to be broken at runtime, the default for fortification will be left at_FORTIFY_SOURCE=2
for Fedora 38. Change owner will do this inredhat-rpm-config
- Contingency deadline: 2023-02-07 to decide if the default should be
_FORTIFY_SOURCE=2
or not. Beta freeze to switch packages with unresolved bugs related to this, to use_FORTIFY_SOURCE=2
. - Blocks release? Yes
- Blocks product? No
Documentation
More context on _FORTIFY_SOURCE=3
improvements.