From: Frederic Berat <fberat@redhat.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Maxim Kuvyrkov via Libc-alpha <libc-alpha@sourceware.org>,
"Carlos O'Donell" <carlos@redhat.com>,
Sam James <sam@gentoo.org>
Subject: Re: [PATCH 01/21] Add --enable-fortify-source option
Date: Thu, 22 Jun 2023 13:48:17 +0200 [thread overview]
Message-ID: <CAObJKZoJy02XO=-O4uXQxucsODAwGqMBH8QgRHQC+MVBifxHHQ@mail.gmail.com> (raw)
In-Reply-To: <d7481145-1b53-ff5d-d390-e2e17fd55acb@gotplt.org>
On Wed, Jun 21, 2023 at 5:26 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 2023-06-21 09:18, Frederic Berat wrote:
> > On Tue, Jun 20, 2023 at 8:19 PM Frédéric Bérat <fberat@redhat.com> wrote:
> >>
> >> It is now possible to enable fortification.
> >> The level may be given as parameter, if none is provided, the configure
> >> script will determine what is the highest level possible that can be set
> >> considering GCC built-ins availability and set it.
> >> If level is explicitly set to 3, configure checks if the compiler
> >> supports the built-in function necessary for it or raise an error if it
> >> isn't.
> >>
> >> The result of the configure checks is 2 variables, $fortify_source and
> >> $no_fortify_source that are used to appropriately populate CFLAGS.
> >>
> >> Since the feature needs some of the routines provided by Glibc, these
> >> are excluded from the fortification.
> >> ---
> >> Makeconfig | 33 ++++++++++++++++++++++++---
> >> config.make.in | 3 ++-
> >> configure.ac | 60 +++++++++++++++++++++++++++++++++++---------------
> >> elf/rtld-Rules | 2 +-
> >> 4 files changed, 75 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/Makeconfig b/Makeconfig
> >> index 2514db35f6..59fbd9ebf9 100644
> >> --- a/Makeconfig
> >> +++ b/Makeconfig
> >> @@ -543,12 +543,13 @@ endif # +link
> >> # ARM, gcc always produces different debugging symbols when invoked with
> >> # a -O greater than 0 than when invoked with -O0, regardless of anything else
> >> # we're using to suppress optimizations. Therefore, we need to explicitly pass
> >> -# -O0 to it through CFLAGS.
> >> +# -O0 to it through CFLAGS. By side effect, any fortification needs to be
> >> +# disabled as it needs -O greater than 0.
> >> # Additionally, the build system will try to -include $(common-objpfx)/config.h
> >> # when compiling the tests, which will throw an error if some special macros
> >> # (such as __OPTIMIZE__ and IS_IN_build) aren't defined. To avoid this, we
> >> # tell gcc to define IS_IN_build.
> >> -CFLAGS-printers-tests := -O0 -ggdb3 -DIS_IN_build
> >> +CFLAGS-printers-tests := -O0 -ggdb3 -DIS_IN_build $(no-fortify-source)
> >>
> >> ifeq (yes,$(build-shared))
> >> # These indicate whether to link using the built ld.so or the installed one.
> >> @@ -901,6 +902,16 @@ define elide-stack-protector
> >> $(if $(filter $(@F),$(patsubst %,%$(1),$(2))), $(no-stack-protector))
> >> endef
> >>
> >> +# We might want to compile with fortify-source
> >> +ifneq ($(fortify-source),)
> >> ++fortify-source=$(fortify-source)
> >> +endif
> >> +
> >> +# Some routine can't be fortified like the ones used by fortify
> >> +define elide-fortify-source
> >> +$(if $(filter $(@F),$(patsubst %,%$(1),$(2))), $(no-fortify-source))
> >> +endef
> >> +
> >> # The program that makes Emacs-style TAGS files.
> >> ETAGS := etags
> >>
> >> @@ -961,6 +972,16 @@ endif # $(+cflags) == ""
> >> $(+stack-protector) -fno-common
> >> +gcc-nowarn := -w
> >>
> >> +# We must filter out elf because the early bootstrap of the dynamic loader
> >> +# cannot be fortified. Likewise we exclude dlfcn because it is entangled
> >> +# with the loader. We must filter out csu because early startup, like the
> >> +# loader, cannot be fortified. Lastly debug is the fortification routines
> >> +# themselves and they cannot be fortified.
> >> +do-fortify = $(filter-out elf dlfcn csu debug,$(subdir))
> >> +ifeq ($(do-fortify),$(subdir))
> >> ++cflags += $(+fortify-source)
> >> +endif
> >
> > This needs to be adapted to deal with compilers that define
> > "_FORTIFY_SOURCE" by default (checked on ubuntu 22.04):
> >
> > +do-fortify = $(filter-out elf dlfcn csu debug,$(subdir))
> > +ifeq ($(do-fortify),$(subdir))
> > ++cflags += $(+fortify-source)
> > +else
> > ++cflags += $(no-fortify-source)
> > +endif
> >
> > That way, we ensure that even if _FORTIFY_SOURCE is enabled at system
> > level, we don't build these subdirectories with it.
>
> That's likely true for Gentoo as well. Additionally, those
> distributions will default to fortification being enabled by default,
> without --enable-fortify-source. This is probably wrong in terms of
> compatibility and user expectations, i.e. without the configure flag,
> the code generated should be like in 2.37, i.e. glibc should strictly
> not be built with fortification enabled.
>
> Sam, do you have an opinion on this? Would it be too surprising for
> Gentoo packaging/users if glibc 2.38 built with fortification on by
> default? FWIW, we'll likely flip to enabling fortification by default
> in 2.39 and make the flag --disable-fortify-source, but that's a
> different bridge to cross.
>
Since I'd like to get some more feedback, I'll keep the behavior as-is
in v2, i.e.:
- If no option is passed to configure, the build environment decides
if _FORTIFY_SOURCE should be set (through exported CFLAGS or
compiler). In other words the "disable" is not enforced with this
patch.
- If "--enable-fortify-source" is set, it overrides any system preset.
I'd be happy to get more feedback on whether I should enforce
disablement or not, especially from people who deal with distribution
that set it by default.
> Thanks,
> Sid
>
next prev parent reply other threads:[~2023-06-22 11:48 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 18:18 [PATCH 00/21] Allow glibc to be built with _FORTIFY_SOURCE Frédéric Bérat
2023-06-20 18:18 ` [PATCH 01/21] Add --enable-fortify-source option Frédéric Bérat
2023-06-20 20:42 ` Joseph Myers
2023-06-21 13:19 ` Frederic Berat
2023-06-21 13:18 ` Frederic Berat
2023-06-21 15:25 ` Siddhesh Poyarekar
2023-06-22 11:48 ` Frederic Berat [this message]
2023-06-22 11:54 ` Siddhesh Poyarekar
2023-06-22 12:29 ` Adhemerval Zanella Netto
2023-06-22 12:50 ` Siddhesh Poyarekar
2023-06-22 19:39 ` Adhemerval Zanella Netto
2023-06-22 21:26 ` Siddhesh Poyarekar
2023-06-23 7:29 ` Frederic Berat
2023-06-23 5:46 ` Sam James
2023-06-20 18:18 ` [PATCH 02/21] Configure: regenerate for autoconf 2.71 Frédéric Bérat
2023-06-20 20:47 ` Joseph Myers
2023-06-22 19:07 ` Florian Weimer
2023-06-23 11:28 ` Carlos O'Donell
2023-06-20 18:18 ` [PATCH 03/21] Exclude routines from fortification Frédéric Bérat
2023-06-20 18:18 ` [PATCH 04/21] sysdeps/{i386,x86_64}/mempcpy_chk.S: fix linknamespace for __mempcpy_chk Frédéric Bérat
2023-06-21 12:27 ` Siddhesh Poyarekar
2023-06-21 17:26 ` Noah Goldstein
2023-06-22 4:02 ` Siddhesh Poyarekar
2023-06-20 18:18 ` [PATCH 05/21] stdio-common: tests: Incorrect maxlen parameter for swprintf Frédéric Bérat
2023-06-21 12:29 ` Siddhesh Poyarekar
2023-06-20 18:18 ` [PATCH 06/21] sysdeps: Ensure ieee128*_chk routines to be properly named Frédéric Bérat
2023-06-20 18:18 ` [PATCH 07/21] string: Ensure *_chk routines have their hidden builtin definition available Frédéric Bérat
2023-06-20 18:18 ` [PATCH 08/21] stdio: " Frédéric Bérat
2023-06-20 18:18 ` [PATCH 09/21] asprintf_chk: Ensure compatibility for both s390x and ppc64le Frédéric Bérat
2023-06-20 18:18 ` [PATCH 10/21] misc/sys/cdefs.h: Create FORTIFY redirects for internal calls Frédéric Bérat
2023-06-20 18:18 ` [PATCH 11/21] wcsmbs/bits/wchar2{,-decl}.h: Clearly separate declaration from definitions Frédéric Bérat
2023-06-22 4:19 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 12/21] wcsmbs/bits/wchar2{,-decl}.h: Avoid PLT entries with _FORTIFY_SOURCE Frédéric Bérat
2023-06-20 18:19 ` [PATCH 13/21] posix/bits/unistd.h: Clearly separate declaration from definitions Frédéric Bérat
2023-06-22 4:17 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 14/21] posix/bits/unistd{,-decl}.h: Avoid PLT entries with _FORTIFY_SOURCE Frédéric Bérat
2023-06-20 18:19 ` [PATCH 15/21] debug/readlink{,at}_chk.c: Harmonize declaration and definition Frédéric Bérat
2023-06-22 4:11 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 16/21] misc/bits/select2.h: Clearly separate declaration from definitions Frédéric Bérat
2023-06-22 4:16 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 17/21] misc/bits/syslog.h: Clearly separate declaration from definition Frédéric Bérat
2023-06-22 4:24 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 18/21] rt/tst-mqueue4.c: Fix wrong number of argument for mq_open Frédéric Bérat
2023-06-21 12:26 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 19/21] sysdeps/ieee754/ldbl-128ibm-compat: Fix warn unused result Frédéric Bérat
2023-06-21 11:56 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 20/21] sysdeps/powerpc/fpu/tst-setcontext-fpscr.c: " Frédéric Bérat
2023-06-21 11:45 ` Siddhesh Poyarekar
2023-06-20 18:19 ` [PATCH 21/21] benchtests: fix " Frédéric Bérat
2023-06-21 11:42 ` Siddhesh Poyarekar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAObJKZoJy02XO=-O4uXQxucsODAwGqMBH8QgRHQC+MVBifxHHQ@mail.gmail.com' \
--to=fberat@redhat.com \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=sam@gentoo.org \
--cc=siddhesh@gotplt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).