Build/security: Try FORTIFY_SOURCE #3575
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a new build-time cmake cache variable: FORTIFY_SOURCE Default to empty, but can be set to 1, 2, or 3, corresponding to setting the _FORTIFY_SOURCE macro available in recent versions of clang and gcc. (I'm not sure exactly which minimum compiler version is needed for each fortification level, except that for level 3, gcc must be 12+.) Fortification involves replacing several "unsafe" memory-related functions such as memcpy, memset, strcpy, etc, with special versions that do bounds checking, aided by some compiler smarts for understanding the likely bounds of different buffers. If I understand correctly, at level 2 it can figure out bounds of constant-sized arrays, and at level 3 it can figure out certain dynamic cases as well. There are two use cases for this: 1. For our own CI, this is yet another bit of static and dynamic anslysis to enable (currently, just in the gcc12 test) to possibly catch bugs. 2. Users who are building OIIO to deploy it in security-sensitive environment may wish to build with some fortification level enabled to help prevent certain memory errors or security issues, understanding that it may slightly impact performance.
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Oct 7, 2022
Add a new build-time cmake cache variable: FORTIFY_SOURCE Default to empty, but can be set to 1, 2, or 3, corresponding to setting the _FORTIFY_SOURCE macro available in recent versions of clang and gcc. (I'm not sure exactly which minimum compiler version is needed for each fortification level, except that for level 3, gcc must be 12+.) Fortification involves replacing several "unsafe" memory-related functions such as memcpy, memset, strcpy, etc, with special versions that do bounds checking, aided by some compiler smarts for understanding the likely bounds of different buffers. If I understand correctly, at level 2 it can figure out bounds of constant-sized arrays, and at level 3 it can figure out certain dynamic cases as well. There are two use cases for this: 1. For our own CI, this is yet another bit of static and dynamic anslysis to enable (currently, just in the gcc12 test) to possibly catch bugs. 2. Users who are building OIIO to deploy it in security-sensitive environment may wish to build with some fortification level enabled to help prevent certain memory errors or security issues, understanding that it may slightly impact performance.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a new build-time cmake cache variable: FORTIFY_SOURCE
Default to empty, but can be set to 1, 2, or 3, corresponding to setting the _FORTIFY_SOURCE macro available in recent versions of clang and gcc. (I'm not sure exactly which minimum compiler version is needed for each fortification level, except that for level 3, gcc must be 12+.)
Fortification involves replacing several "unsafe" memory-related functions such as memcpy, memset, strcpy, etc, with special versions that do bounds checking, aided by some compiler smarts for understanding the likely bounds of different buffers. If I understand correctly, at level 2 it can figure out bounds of constant-sized arrays, and at level 3 it can figure out certain dynamic cases as well.
There are two use cases for this:
For our own CI, this is yet another bit of static and dynamic anslysis to enable (currently, just in the gcc12 test) to possibly catch bugs.
Users who are building OIIO to deploy it in security-sensitive environment may wish to build with some fortification level enabled to help prevent certain memory errors or security issues, understanding that it may slightly impact performance.