Skip to content
  • KJ Tsanaktsidis's avatar
    0ccb80d6
    Extract hardening CFLAGS to a special $hardenflags variable · 0ccb80d6
    KJ Tsanaktsidis authored
    This changes the automatic detection of -fstack-protector,
    -D_FORTIFY_SOURCE, and -mbranch-protection to write to $hardenflags
    instead of $XCFLAGS. The definition of $cflags is changed to
    "$hardenflags $orig_cflags $optflags $debugflags $warnflags" to match.
    
    Furthermore, these flags are _prepended_ to $hardenflags, rather than
    appended.
    
    The implications of doing this are as follows:
    
    * If a CRuby builder specifies cflags="-mbranch-protection=foobar" at
      the ./configure script, and the configure script detects that
      -mbranch-protection=pac-ret is accepted, then GCC will be invoked as
      "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar". Since
      the last flags take precedence, that means that user-supplied values
      of these flags in $cflags will take priority.
    * Likewise, if a CRuby builder explicitly specifies
      "hardenflags=-mbranch-protection=foobar", because we _prepend_ to
      $hardenflags in our autoconf script, we will still invoke GCC as
      "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar".
    * If a CRuby builder specifies CFLAGS="..." at the configure line,
      automatic detection of hardening flags is ignored as before.
    * C extensions will _also_ be built with hardening flags now as well
      (this was not the case by default before because the detected flags
      went into $XCFLAGS).
    
    Additionally, as part of this work, I changed how the detection of
    PAC/BTI in Context.S works. Rather than appending the autodetected
    option to ASFLAGS, we simply compile a set of test programs with the
    actual CFLAGS in use to determine what PAC/BTI settings were actually
    chosen by the builder. Context.S is made aware of these choices through
    some custom macros.
    
    The result of this work is that:
    
    * Ruby will continue to choose some sensible defaults for hardening
      options for the C compiler
    * Distributors are able to specify CFLAGS that are consistent with their
      distribution and override these defaults
    * Context.S will react to whatever -mbranch-protection is actually in
      use, not what was autodetected
    * Extensions get built with hardening flags too.
    
    [Bug #20154]
    [Bug #20520]
    0ccb80d6
    Extract hardening CFLAGS to a special $hardenflags variable
    KJ Tsanaktsidis authored
    This changes the automatic detection of -fstack-protector,
    -D_FORTIFY_SOURCE, and -mbranch-protection to write to $hardenflags
    instead of $XCFLAGS. The definition of $cflags is changed to
    "$hardenflags $orig_cflags $optflags $debugflags $warnflags" to match.
    
    Furthermore, these flags are _prepended_ to $hardenflags, rather than
    appended.
    
    The implications of doing this are as follows:
    
    * If a CRuby builder specifies cflags="-mbranch-protection=foobar" at
      the ./configure script, and the configure script detects that
      -mbranch-protection=pac-ret is accepted, then GCC will be invoked as
      "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar". Since
      the last flags take precedence, that means that user-supplied values
      of these flags in $cflags will take priority.
    * Likewise, if a CRuby builder explicitly specifies
      "hardenflags=-mbranch-protection=foobar", because we _prepend_ to
      $hardenflags in our autoconf script, we will still invoke GCC as
      "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar".
    * If a CRuby builder specifies CFLAGS="..." at the configure line,
      automatic detection of hardening flags is ignored as before.
    * C extensions will _also_ be built with hardening flags now as well
      (this was not the case by default before because the detected flags
      went into $XCFLAGS).
    
    Additionally, as part of this work, I changed how the detection of
    PAC/BTI in Context.S works. Rather than appending the autodetected
    option to ASFLAGS, we simply compile a set of test programs with the
    actual CFLAGS in use to determine what PAC/BTI settings were actually
    chosen by the builder. Context.S is made aware of these choices through
    some custom macros.
    
    The result of this work is that:
    
    * Ruby will continue to choose some sensible defaults for hardening
      options for the C compiler
    * Distributors are able to specify CFLAGS that are consistent with their
      distribution and override these defaults
    * Context.S will react to whatever -mbranch-protection is actually in
      use, not what was autodetected
    * Extensions get built with hardening flags too.
    
    [Bug #20154]
    [Bug #20520]
Loading