Systemtap on linux does not properly apply hardening CFLAGS when compiling using --with-dtrace #131865
Comments
This comment has been minimized.
This comment has been minimized.
stratakis
added a commit
to stratakis/cpython
that referenced
this issue
Mar 29, 2025
…builds When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect dtrace invocation on Solaris/Oracle/MacOS
stratakis
added a commit
to stratakis/cpython
that referenced
this issue
Mar 29, 2025
…builds When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/Oracle/MacOS
vstinner
pushed a commit
that referenced
this issue
Mar 31, 2025
…#131866) When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/macOS.
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Mar 31, 2025
…builds (pythonGH-131866) When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/macOS. (cherry picked from commit 0cd4bef) Co-authored-by: stratakis <[email protected]>
vstinner
pushed a commit
that referenced
this issue
Mar 31, 2025
… builds (GH-131866) (#131950) gh-131865: Properly apply exported CFLAGS for dtrace/systemtap builds (GH-131866) When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/macOS. (cherry picked from commit 0cd4bef) Co-authored-by: stratakis <[email protected]>
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Mar 31, 2025
…builds (pythonGH-131866) When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/macOS. (cherry picked from commit 0cd4bef) Co-authored-by: stratakis <[email protected]>
|
Fixed by change 0cd4bef. |
vstinner
pushed a commit
that referenced
this issue
Mar 31, 2025
… builds (GH-131866) (#131951) gh-131865: Properly apply exported CFLAGS for dtrace/systemtap builds (GH-131866) When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/macOS. (cherry picked from commit 0cd4bef) Co-authored-by: stratakis <[email protected]>
seehwan
pushed a commit
to seehwan/cpython
that referenced
this issue
Apr 16, 2025
…builds (python#131866) When using --with-dtrace the resulting object file could be missing specific CFLAGS exported by the build system due to the systemtap script using specific defaults. Exporting the CC and CFLAGS variables before the dtrace invocation allows us to properly apply CFLAGS exported by the build system even when cross-compiling. The fix does not affect the dtrace invocation on Solaris/macOS.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
When compiling using --with-dtrace, Linux uses the systemtap script which utilizes a common default CFLAGS set to provide the object file. When extra hardening flags are passed during the compilation through the build environment, dtrace is not capturing them, resulting in the final binary or shared library missing some protections.
This behavior was documented recently
Discovered when testing the -mbranch-protection=standard on aarch64 where pydtrace.o was missing the proper gnu property and the relevant hardware protections.
See https://bugzilla.redhat.com/show_bug.cgi?id=2350935
In order to fix that, adding the CFLAGS variable to the Makefile before the dtrace invocation resolves the issue.
On systems that use the original dtrace, changing the CFLAGS there should have no effects.
php dealt with a similar issue before, see:
php/php-src@717b367
php/php-src@475fd29
php/php-src@02b3fb1
CPython versions tested on:
CPython main branch, 3.14, 3.13, 3.12, 3.11, 3.10, 3.9
Operating systems tested on:
Linux
Linked PRs
The text was updated successfully, but these errors were encountered: