FORTIFY_SOURCE check from Debug build type
#30824
FORTIFY_SOURCE should be used if ENABLE_HARDENING=ON and optimisations are being used. This should not be coupled to any particular build type, because even if the build type is Debug, optimisations might still be in use.
Fixes: #30800. Also somewhat of a followup to #30778 (review).
`FORTIFY_SOURCE` should be used if `ENABLE_HARDENING=ON` and optimisations
are being used. This should not be coupled to any particular build type,
because even if the build type is `Debug`, optimisations might still
be in use.
Fixes: #30800.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | ryanofsky, TheCharlatan |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
484+ # _FORTIFY_SOURCE requires that there is some level of optimization,
485+ # otherwise it does nothing and just creates a compiler warning.
486 try_append_cxx_flags("-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3"
487 RESULT_VAR cxx_supports_fortify_source
488+ SOURCE "int main() {
489+ # if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
Debug, it tests if optimisations are being used directly.
The check above reminds me of the part of the XZ backdoor where the attacker inserted a single . character to disable a linux security feature in a similar cmake check:
So I think it might be useful to add a sanity check to confirm that cxx_supports_fortify_source is actually true in release builds:
0if(NOT cxx_supports_fortify_source AND CMAKE_BUILD_TYPE MATCHES "Release")
1 message(FATAL_ERROR "Error: Current release build flags are incompatible with fortify_source")
2endif()
Separately, one theoretical drawback of this new implementation is it probably disables fortify source unconditionally in multi-configuration cmake backends like visual studio and xcode, whereas the previous $<$<NOT:$<CONFIG:Debug>>: generator expression was more flexible and it could enable fortify source in release configurations while disabling it in debug configurations. But I think this doesn’t matter in practice because source fortification is a GNU feature which presumably doesn’t work in visual studio or xcode anyway.
I am certainly open to additional approaches in regards to the (potential fragility) of inline source.
So I think it might be useful to add a sanity check to confirm that cxx_supports_fortify_source is actually true in release builds:
I have a PR to try and do this in #27038.
-Werror=cpp? This should avoid the need for any C++ source code?
ACK 30803a35d54acda19ded88474c205f8954fea5e1
Tested by adding -DAPPEND_CXXFLAGS="-O0" to the build configuration.