Repository navigation
build: Add security hardening build options - #2174
Merged
Merged
Conversation
Port OpenImageIO's hardening build options: the original feature from OIIO PR 4538 as fixed by OIIO PRs 4996 and 5318. A new OSL_HARDENING cache variable (also settable from the environment) selects a level: 0=none, 1=fast (the default for non-Debug builds), 2=extensive (the default for Debug builds), 3=debug. Depending on the level, compiler, and build type, it enables: * Position-independent code, -fstack-protector-strong. * _FORTIFY_SOURCE, except in Debug builds (it needs optimization) and with address or memory sanitizers (which predefine it to 0). * _GLIBCXX_ASSERTIONS for gcc >= 14 at levels 2 and 3. * libc++ hardening modes (_LIBCPP_HARDENING_MODE) FAST, EXTENSIVE, or DEBUG to match the level. Differences from the OIIO version: * OSL passes the directory's compile definitions to the clang commands that make the LLVM bitcode for the JIT (llvm_ops) and for the GPU. Fortified libc calls (__memcpy_chk, etc.) and libc++ assertion handlers don't belong in JIT or device code. So compiler.cmake now sets HARDENING_DEFINITIONS, and EMBED_LLVM_BITCODE_IN_CPP and MAKE_CUDA_BITCODE filter those definitions out. * OIIO tests the undefined variables OIIO_CLANG_VERSION and OIIO_APPLE_CLANG_VERSION before setting _LIBCPP_HARDENING_MODE, so libc++ hardening never turns on there. Here we test CLANG_VERSION_STRING >= 18 or APPLECLANG_VERSION_STRING >= 17 (Apple clang 17 is the first to ship a libc++ with hardening modes). CI: like OIIO, test level 2 on the bleeding-edge job. OSL has no analog of OIIO's "all local builds" job, which uses level 3, so level 3 goes on the gcc-14 latest-releases job instead. Assisted-by: Claude Code / Claude Opus 5.5 Signed-off-by: Larry Gritz <lg@larrygritz.com>
Collaborator
Author
|
No objections for 3 weeks -> merge |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Port OpenImageIO's hardening build options: the original feature from OIIO PR 4538, with fixes by OIIO PRs 4996 and 5318.
A new OSL_HARDENING cache variable (also settable from the environment) selects a level: 0=none, 1=fast (the default for non-Debug builds), 2=extensive (the default for Debug builds), 3=debug. Depending on the level, compiler, and build type, it enables:
Differences from the OIIO version:
CI: like OIIO, test level 2 on the bleeding-edge job. OSL has no analog of OIIO's "all local builds" job, which uses level 3, so level 3 goes on the gcc-14 latest-releases job instead.
Assisted-by: Claude Code / Claude Opus 5.5