Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 609048 - >=sys-libs/glibc-2.25: Pass --enable-stack-protector=strong or --enable-stack-protector=all to configure
Summary: >=sys-libs/glibc-2.25: Pass --enable-stack-protector=strong or --enable-stack...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: glibc-2.25
  Show dependency tree
 
Reported: 2017-02-12 09:18 UTC by Arfrever Frehtes Taifersar Arahesis
Modified: 2022-02-05 07:16 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis 2017-02-12 09:18:46 UTC
sys-libs/glibc/files/eblits/common.eblit still contains:

	# building glibc with SSP is fraught with difficulty, especially
	# due to __stack_chk_fail_local which would mean significant changes
	# to the glibc build process. See bug #94325 #293721
	# Note we have to handle both user-given CFLAGS and gcc defaults via
	# spec rules here.  We can't simply add -fno-stack-protector as it gets
	# added before user flags, and we can't just filter-flags because
	# _filter_hardened doesn't support globs.
	filter-flags -fstack-protector*
	gcc-specs-ssp && append-flags $(test-flags -fno-stack-protector)


So -fno-stack-protector is appended.

NEWS file of glibc 2.25 contains:

* Most of glibc can now be built with the stack smashing protector enabled.
  It is recommended to build glibc with --enable-stack-protector=strong.
  Implemented by Nick Alcock (Oracle).
...
The following bugs are resolved with this release:
...
  [7065] build: Support building glibc with -fstack-protector or -fstack-
    protector-all


configure.ac of glibc 2.25 contains:

dnl Build glibc with -fstack-protector, -fstack-protector-all, or
dnl -fstack-protector-strong.
AC_ARG_ENABLE([stack-protector],
              AC_HELP_STRING([--enable-stack-protector=@<:@yes|no|all|strong@:>@],
                             [Use -fstack-protector[-all|-strong] to detect glibc buffer overflows]),
              [enable_stack_protector=$enableval],
              [enable_stack_protector=no])
case "$enable_stack_protector" in
all|yes|no|strong) ;;
*) AC_MSG_ERROR([Not a valid argument for --enable-stack-protector: \"$enable_stack_protector\"]);;
esac
...
if test "$enable_stack_protector" = yes && test "$libc_cv_ssp" = yes; then
  stack_protector="-fstack-protector"
  AC_DEFINE(STACK_PROTECTOR_LEVEL, 1)
elif test "$enable_stack_protector" = all && test "$libc_cv_ssp_all" = yes; then
  stack_protector="-fstack-protector-all"
  AC_DEFINE(STACK_PROTECTOR_LEVEL, 2)
elif test "$enable_stack_protector" = strong && test "$libc_cv_ssp_strong" = yes; then
  stack_protector="-fstack-protector-strong"
  AC_DEFINE(STACK_PROTECTOR_LEVEL, 3)
else
  stack_protector="-fno-stack-protector"
  AC_DEFINE(STACK_PROTECTOR_LEVEL, 0)
fi
AC_SUBST(libc_cv_ssp)
AC_SUBST(stack_protector)
AC_SUBST(no_stack_protector)


So when no --enable-stack-protector=... option is passed to configure, -fno-stack-protector is used by build system anyway.

Maybe it would be reasonable to disable 'gcc-specs-ssp && append-flags $(test-flags -fno-stack-protector)' line in common.eblit for glibc >=2.25 and to pass --enable-stack-protector=strong or --enable-stack-protector=all to configure?
(Regardless of USE="-hardened" / USE="hardened")
Comment 1 Matthias Maier gentoo-dev 2017-06-16 08:30:04 UTC
commit 9fe8087634d878eeed259019bf6f3eb19ef209b8
Author: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Date:   Wed Jun 14 16:31:44 2017 +0200

    toolchain-glibc.eclass: Build most of >=sys-libs/glibc-2.25 with -fstack-protector-all (bug #609048).
    
    configure accepts --enable-stack-protector=... option which results
    in build system passing appropriate -fstack-protector... option
    when possible.
    
    Signed-off-by: Matthias Maier <tamiko@gentoo.org>