cpython icon indicating copy to clipboard operation
cpython copied to clipboard

gh-112301: Add fortify source level 3 to default compiler options

Open nohlson opened this issue 1 year ago • 4 comments

gh-112301: Added -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 to default compiler options for all builds

This option adds runtime protections for glibc to abort execution when unsafe behavior is encountered. Here are the GNU docs on the option

This is a very brief writeup that I found useful from Red Hat explaining some benefits

Also the OpenSSF compiler hardening guidance gives a very good description of the option

This is an option that theoretically affects the runtime so pyperformance benchmarks were run. The benchmark for this branch shows little overall impact but does impact some benchmark types:

NOTE: I would recommend looking into the details of the benchmarks in the links

Tag Geometric Mean
apps 1.00x slower
asyncio Not Significant
math 1.01x faster
regex 1.03x slower
serialize 1.01x faster
startup 1.00x faster
template 1.00x slower
overall 1.00x faster

A benchmark was run a few weeks ago with this option that was slightly different:

Tag Geometric Mean
apps 1.03x slower
asyncio 1.01x slower
math 1.00x slower
regex 1.02x faster
serialize 1.01x slower
startup 1.01x slower
template 1.01x slower
overall 1.01x slower

The benchmarks show that overall there is little memory impact and overall very small performance impact but within benchmark types there is some movement . Many compilers use -D_FORTIFY_SOURCE=2 by default. Level 3 adds additional bounds checking. My recommendation and the recommendation of the OpenSSF guidance is to raise to level 3 for this protection but would like to discuss further.

Attn: @mdboom

nohlson avatar Jul 08 '24 23:07 nohlson

@corona10 can we test with buildbots?

nohlson avatar Jul 08 '24 23:07 nohlson

:robot: New build scheduled with the buildbot fleet by @corona10 for commit 453e34fa3ef4b3f223dd7429617aae89677ffec0 :robot:

If you want to schedule another build, you need to add the :hammer: test-with-buildbots label again.

bedevere-bot avatar Jul 09 '24 00:07 bedevere-bot

All commit authors signed the Contributor License Agreement.
CLA signed

ghost avatar Jul 09 '24 15:07 ghost

@nohlson I will take a look at this PR by this weekend, sorry, I am too busy these days.

corona10 avatar Jul 11 '24 15:07 corona10

@nohlson I have 2 questions.

  1. Is this flag the subset of the overall policy that we want to measure? Consider applying flags for warnings about potential security issues #112301 (comment)
  2. Do you have a plan to provide some kind of ./configure --disable-openssf-guide?
  1. This is a subset of the overall policy based on the OpenSSF guidance.
  2. I do not intend to add an argument to configure to turn off these options, however I would be interested in maybe including the ability to disable the new options that do impact performance benchmarks. This is theoretically one of those options however we didn't see a measurable impact. I could see there being a configure argument that disables the performance impacting options if we were to introduce one that has a measurable impact.

I would prefer the options we introduce for this effort to be always on, and put a lot of consideration into benchmark impacting options we do include, and possibly not enabling them if we deem the impact too much rather than enabling everything and making a new configure argument.

nohlson avatar Jul 17 '24 03:07 nohlson

@nohlson

I do not intend to add an argument to configure to turn off these options, however I would be interested in maybe including the ability to disable the new options that do impact performance benchmarks.

I am pretty sure that there will be users who want to disable options that we added for the OpenSSF guide with a single configuration command :) Adding the optional argument will be helpful to them(even if enabling OpenSSF options is more recommended), I will submit the PR in this week.

corona10 avatar Jul 18 '24 16:07 corona10

This change broke RHEL8 buildbot, test_cext and test_cppext fail with:

  /usr/include/features.h:393:5: error: #warning _FORTIFY_SOURCE > 2 is treated like 2 on this platform [-Werror=cpp]
   #   warning _FORTIFY_SOURCE > 2 is treated like 2 on this platform
       ^~~~~~~
  cc1plus: all warnings being treated as errors

vstinner avatar Jul 18 '24 20:07 vstinner

@nohlson Would you like to check?

corona10 avatar Jul 19 '24 00:07 corona10

I suggest checking for the FORTIFY flag using -Werror in configure.

vstinner avatar Jul 19 '24 08:07 vstinner

I suggest checking for the FORTIFY flag using -Werror in configure.

We already do.

erlend-aasland avatar Jul 19 '24 11:07 erlend-aasland

We already do.

For other flags yes, but apparently, not for _FORTIFY_SOURCE=3:

# Enable flags that warn and protect for potential security vulnerabilities.
# These flags should be enabled by default for all builds.
AX_CHECK_COMPILE_FLAG([-fstack-protector-strong], [BASECFLAGS="$BASECFLAGS -fstack-protector-strong"], [AC_MSG_WARN([-fstack-protector-strong not supported])], [-Werror])
AX_CHECK_COMPILE_FLAG([-Wtrampolines], [BASECFLAGS="$BASECFLAGS -Wtrampolines"], [AC_MSG_WARN([-Wtrampolines not supported])], [-Werror])
AX_CHECK_COMPILE_FLAG([-D_FORTIFY_SOURCE=3], [BASECFLAGS="$BASECFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3"], [AC_MSG_WARN([-D_FORTIFY_SOURCE=3 not supported])])

vstinner avatar Jul 20 '24 18:07 vstinner